[Vortex] Rebol Script-Binding / Callback Problem

Francis Brosnan Blazquez francis at aspl.es
Tue Mar 15 19:44:51 CET 2011

Hi Sam,

> Yes, that's the approach I described in paragraph 3, its basically
> building a new api on top of vortex.
> Either way, its a lot of work. Gatewaying through http+json would be
> easier. Or even gatewaying http/soap into beep/soap, which I think
> vortex supports.

Ok, I think we don't agree on this point: I clearly see this is more
work than marshalling into a queue...it would be ironic to use an
application protocol to communicate with your application protocol,
don't you think?

> The async queue might work, might not, at the time I looked it seemed
> that some callbacks had return values, so you couldn't queue their
> args as an event and then return, you'd have queue the args, then
> block waiting for an event to come back. Whether this would block
> threads for too long, I don't know. My attempt at this failed, I got
> intermittent deadlocks. Probably I was doing something wrong, but
> having the full pain of threads thrust upon me in my attempt to
> unthread felt unpleasantly ironic.

Ok, In general, handler that do require to return a value back to the
library, have support to defer decision (like channel close or channel
start does) to avoid locking on that handler...

The rest of worker handlers (for example, frame received, connection
close,..) isn't a problem taking too long...

Maybe it is a matter of looking what was the problem Sam...:-?

> Honestly, Francis, I don't understand why vortex doesn't use a
> single-threaded event-based model. Threads are useful for servers that
> can block on disk I/O, but network connections have supported i/o
> multiplexing for a long time. The decision to use threads in a library
> forces apps using vortex to be threaded (or to somehow dethread using
> some sync mechanism), which is a pretty fundamental architectural
> decision to be pushed onto an application by a library. 

Which one isn't? I mean, it is hard to take a decision that won't affect
upper levels. In an alternative situation, if we had opted in for
non-threaded model, people would argue vortex has poor performance...why
didn't use threads??

>From the first time we wanted a high performance BEEP library with
support for parallel tasking, especially suited for servers...

> Its simple to
> use an event-based library in a multi-threaded app, using a
> multithreaded library in an event-based or single-threaded app is
> possibe, but not easy.

..you are right, however, it is hard to turn an event-based library into
a thread based library, especially at the server side, mainly because
you need lot of testing to ensure there are no races, which is the
natural trend in event based or single loop engines..

> Its not just interpreter cores that are hostile to multi-threading,
> every gui library I've ever heard of is, too. I tried to build a
> simple GUI chat client with QT and vortex, every callback had to post
> things back to the thread main loop. Quite painful.

I'm with you it is, but remember this only happens with toolkits with
poor thread support (assuming it is the case), I mean, python is not an
exception, Gtk+ has a very simple mechanism for threading (calling to
gdk_threads_enter -> touch the interface -> gdk_threads_leave, and you
are done with threads...), Mono and MS.NET have automatic support
(tested) for threads coming from vortex...

I can't believe Qt does not have a similar mechanism to integrate with
thread without pain...

Francis Brosnan Blázquez <francis.brosnan at aspl.es>
91 134 14 22 - 91 134 14 45 - 91 116 07 57


Este mensaje se dirige exclusivamente a su destinatario. Los datos
incluidos en el presente correo son confidenciales y sometidos a secreto
profesional, se prohíbe divulgarlos, en virtud de las leyes vigentes. Si
usted no lo es y lo ha recibido por error o tiene conocimiento del mismo
por cualquier motivo, le rogamos que nos lo comunique por este medio y
proceda a destruirlo o borrarlo.

En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
diciembre, de Protección de Datos de Carácter Personal, le informamos de
que sus datos de carácter personal, recogidos de fuentes accesibles al
público o datos que usted nos ha facilitado previamente, proceden de
bases de datos propiedad de Advanced Software Production Line, S.L.
(ASPL). No obstante, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y oposición dispuestos en la mencionada Ley
Orgánica, notificándolo por escrito a:
ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de
Henares (Madrid).

More information about the Vortex mailing list