[Vortex] Rebol Script-Binding / Callback Problem

"Robert M. Münch" robert.muench at robertmuench.de
Tue Mar 15 19:19:59 CET 2011

Am 14.03.2011 um 19:22 schrieb Sam Roberts:

> Most interpreter cores don't support multithreading in a way that's at
> all helpful with libraries like vortex. Python is exceptional in that
> it does, with a global lock.

Good info, so Rebol's creator should take a look there how they implemented it.

> I tried to bind vortex into lua, which I suspect has the same
> structure as rebol (which I've looked at briefly, but years ago,
> thought it was dead, actually).

OT: Well, Rebol is not widely spread but definitely worth a look. But you won't have zillions of pre-written libs etc. but I never needed this, and we are still doing commercial software in Rebol. 

> I think the only way to work this is to write a multithreaded library
> that implements a single-threaded interface to vortex, and where all
> callback responses are queued up to be handled by a single thread, and
> that single thread interacts with the interpreter core.

I used a hack-trick. As a callback with INTEGER data works. I just use this working callback to trigger a read-messages call from the interpreter. Which reads all messages stored in an async-queue. It's one ping-pong more but does the job.

> Doing this and
> exposing the full vortex API is hard, but if you limit your API to a
> small set of interactions, it might not be too bad. You'd basically
> "post" requests to your lib, and "pull" responses back from it when
> it's ready.

Exactly. The interface I have done is very high-level:
- send message
- get message
- transfer file
- connect server
- disconnect server

That's it. Simple and powerful. And all the fuzz below it isn't exposed nor necessary to be exposed.

> You can try to use swirl as a base, if you _really_ want this in
> rebol, its based on the non-threaded beepcore-c:

Hmm... overkill and complex.

> IMO, the easiest way to use vortex/beep from rebol or any other
> language would probably be to write an http/json-rpc server that
> gateways to beep. Most languages allow parallel interactions with http
> servers (usually using poll, or other event notification facilities)
> natively, and you could take advantage of vortex's beep
> implementation.

Well, this makes deployment of such solutions not easy. Using localhost TCP transfer of messages would be possible to do too. I tried this and works too. But it's not fun to maintain.


More information about the Vortex mailing list