On Wed, Nov 14, 2012 at 4:54 PM, Ted Ross <tr...@redhat.com> wrote:

> One of the problems we've had for a long time with wrapped bindings is the
> mismatch of threading models.  For example, a Ruby program using an
> extension module written in C/C++ will hang if a call into the extension
> blocks.  This is because the extension uses pthreads and the host program
> uses "greenthreads" (i.e. some layered threading mechanism in the scripting
> language).  This is also an issue for Python (and probably every other
> scripting language).
> The proper solution for proton/messenger (which necessarily has a few
> blocking calls) is to provide (or allow the developer to provide) a driver
> written in the scripting language using the same threading library that
> their program uses.
> The proton code structure allows for such a strategy, but the packaging
> does not.  I think that the proton project should make the necessary
> adjustments to encourage developers to contribute "native" drivers for
> Ruby, Python-eventlet, etc.

How does the packaging prevent this?

I'm interested in others' thoughts on this and what would be necessary to
> make this happen.

 I think what's needed is to "engine-ify" Messenger, which involves two

  1) Develop the non-blocking aspects of the API. This might just involve a
few additions to the current API or possibly adding a distinct non-blocking
API which would be a layer underneath the current API. Either way, this
non-blocking API then becomes the top half of the messenger engine.

  2) Develop the bottom half API for the messenger engine. This would in
part simply be an API that would provide access to a set of transport
objects along with connection details. This would presumably also need to
expose a way for the messenger to listen (or ask the driver to listen) on a
given host/port also in order to support the full range of behaviour that
messenger currently does. This latter part might be as simple as providing
access to the list of subscriptions.


Reply via email to