[Vortex] Rebol Script-Binding / Callback Problem

[Francis Brosnan Blázquez]

Hi Sam,

> > >From the first time we wanted a high performance BEEP library with
> > support for parallel tasking, especially suited for servers...
> 
> Whether threads help network server performance is debated (I'm in the
> "doesn't help" camp):
> 
> http://www.kegel.com/c10k.html

I didn't state threads helps network server performance per se, but the
overall server performance, especially when it comes to handle several
operations including IO at the same time, and this is a well know
fact..showed by real experience with available products using different
I/O models, not only with vortex...and this is becoming more important
specially since processors includes several cores, pipelines...

> I realize I'm coming dangerously close to trolling here, sorry,

;-) don't worry..

> however, consider that zmq is internally threaded but has bindings to
> dozens of languages, including rebol:
> 
> http://www.zeromq.org/bindings:lua
> 
> because its threading is hidden internally and not revealed through
> the api. Binding to it is easy, so zmq is taking off.

...ok, but as everything, it has another side; zmq model, forces you to
pull for data from the API, you don't have any async notification....if
you want to cancel a wait for data operation that never comes..surprise
you can't! ..so your single threaded app is blocked for ever...

...now wait, let's fix this, I'll create a separate thread to do all 0mq
communication to avoid my app to get blocked when a single IO reply
don't come.....so, what's the point?

In the other hand, I think it is easier to build a binding for a product
that only has 10 or so API functions, don't you think?

> >> 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..
> 
> Hm, well, I find that opinion surprising. Usually supporters of
> threads claim simplicity of code, better
> use of multi-core for cpu bound servers, and poor async disk i/o on
> non-windows systems.

I didn't wanted to start this thread, but yes, those are also good
reasons too....

> Threads pretty much motivate most discussions of race conditions and
> synchronization in my OS courses, and turning an event based lib into
> a multi-threaded is easy... you have multiple threads listen on the
> event queue, and voila, multi-threaded.

Uhmn.....don't agree at all.

> > I can't believe Qt does not have a similar mechanism to integrate
> with
> > thread without pain...
> 
> Sure it does:
> 
> https://github.com/sam-github/swirl/blob/master/qt/main.cpp
> 
> See at the bottom where every C callback I marshall the data, post it
> to the main loop, and then in the main loop switch on event types,
> pull the data out of the message, then make my single method call to
> QT? Thats a fair amount of typing to stick a string in a window.

Ok, so this confirms QT does not have a simple mechanism if you still
need to do all this stuff..

> Painful is too strong a word, I regret it, but it is surely tedious.

Certainly...

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

AVISO LEGAL
 
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).
 
ASPL garantiza que los datos serán tratados con la finalidad de mantener
las oportunas relaciones comerciales o promocionales con usted o la
entidad que usted representa. 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).