[Vortex] Anybody have binding of vortex into Lua?

[Francis Brosnan Blazquez]

El vie, 22-09-2006 a las 10:46 -0700, Sam Roberts escribió:

Hi Sam!

> On Fri, Sep 22, 2006 at 07:10:16PM +0200, Francis Brosnan Blazquez wrote:
> > > I like vortex, and I'm hoping to use it in upcoming projects, but
> > > its use of threading makes it impossible to bind into ruby [*],
> > > which would be my language of choice.
> > 
> > Not impossible, at least, not directly ;-)
> 
> > You can always make the asynchrouns API to be behave synchronously,
> > which is the way we use vortex library inside our C# applications. 
> 
> 
> > In fact, most of the API is dual (i.e: vortex_connection_new and
> > vortex_channel_new don't create threads if no notification handler is
> > provided). 
> 
> Do you not have to call vortex_listener_wait(), then? It looked to me
> like when a connection request came in a callback to C was made, and
> that callback had to figure out whether to accept or reject the
> connection before returning.

Pretty right Sam. Let me to clarify me words about the DUAL API.

When I was thinking about building the binding, I was doing so taking
into consideration that the first step was building a binding for the
client side (and then, looking at the result, take into the server side
binding). 

In such context, at the client side, vortex_listener_wait is never used,
as you know, but throws an interesting question: what to do on the
server side if a binding is also required? In short, the same.

Inside Vortex documentation, every listener example contains a call to
vortex_listener_wait because we need a way to make the main rutine to
block letting the set of threads started to do its job.

However, as you may be guessing, if you start a BEEP server inside the
context of a runtime, with its own event loop like ruby or Gtk, you
don't need the vortex_listner_wait artifact (and always supposing you
are starting a BEEP server, all of this do not applies to BEEP client
side).

To ilustrate this, attached goes a BEEP echo profile server
implementation entirely written without using callbacks (actually it
uses callbacks, but they won't get inside the ruby runtime). The example
shows how a function like "queue_reply" could be used to make vortex to
work as a loop, even at the server side.

But...

> In theory, I would store the callback arguments somewhere, notify the
> main ruby thread to wake up (probably write a byte to pipe to wake
> up the ruby interpreter's select), the ruby code would then make
> vortex calls on those callback arguments (but from a different thread
> than that which called the callback), and then pass control back
> to the callback. This all seemed quite complex, though, and I'm not
> even sure it would work!
> 
> That impression was from an afternoons playing with the example code a
> fair while ago, though.

With a bit of work this will also do but, as it happens with the
proposed solution on the attached example, I suspect that we should look
into integrate the socket handling inside the ruby event loop as you
have suggested.

See next..

> > A more evolved approach could be trying to integrate the Vortex into the
> > ruby event loop which I don't know if it would be possible [3].
> 
> Ruby's event loop is very simple. The rules are:
> 
> - Only the one interpreter thread can make ANY calls to ANY ruby APIs.
>   No exceptions.
> 
> - The interpreter loops on select. When select wakes on i/o readiness,
>   it then activates the ruby "thread" that had "blocked" on that fd.
>   From ruby, it looks like you have a real o/s thread and do blocking
>   calls, but internally those blocking calls are implemented by calls to
>   select (or as a "context" switch if other threads are ready).

Pretty clear.

> Give the above, what approach would you suggest?

Uhmmn..So, if I understand, the problem is reduced to make the sockets
handled by vortex to not be watched by its own select(2) code but by
the ruby one (replace ruby by the preferred event-loop based
environment). 

Then, when ruby select(2) handling wakeups, it gives the control to
the vortex-ruby binding, making a call to the vortex API to notify
that something happend on a particular socket that must be handled
(for the example those tasks that must be done by the vortex reader
process).

Supposing this, this will require to update vortex reader internals to
support current configuration plus a way to activate vortex reader
process handling on a socket that was handled by external select(2)
code. 

Would this work Sam?

> > Knowing this, will be this enough to try a ruby binding for Vortex and
> > build that chat application with ruby? 
> 
> I have other reasons for trying lua first. If I had all the time I
> wanted, I would also do ruby... but I don't have that much time. I will
> see what I can do.
> 
> I don't need a chat application, of course, but it seems a good way
> to get up to speed on Qt, vortex, and lua. If I can get my lua and Qt
> apps chatting over vortex, I can throw the code away and do something
> interesting.

I see. This approach looks good. The lua binding will be easier than
the ruby binding, knowing that it performs well with threaded
libraries.

Cheers!

> Cheers,
> Sam
> 
> 
> _______________________________________________
> Vortex mailing list
> Vortex at lists.aspl.es
> http://lists.aspl.es/cgi-bin/mailman/listinfo/vortex
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vortex-server-without-cbs.c
Type: text/x-csrc
Size: 2877 bytes
Desc: not available
Url : http://lists.aspl.es/pipermail/vortex/attachments/20061004/033722ea/vortex-server-without-cbs.c