[Vortex] Rebol Script-Binding / Callback Problem

[Sam Roberts]

On Tue, Mar 15, 2011 at 11:44 AM, Francis Brosnan Blazquez
<francis at aspl.es> wrote:
>> 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?

It lacks elegance, yes, but would avoid writing bindings into every
language. How much work
it would be is debatable, I just wanted to point out it is an option
that allows avoiding language bindings.

> >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 realize I'm coming dangerously close to trolling here, sorry,
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.

>> 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.

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.

> 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.

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

Cheers,
Sam