On 06/30/2011 11:55 AM, Alan Conway wrote:
On 06/29/2011 07:43 PM, Darryl L. Pierce wrote:
On Wed, Jun 29, 2011 at 04:58:36PM +0100, Gordon Sim wrote:
...another approach is to ensure that the API being SWIGed supports
non-blocking usage effectively. Though that will take more effort it
seems a nicer solution long term.
I would certainly like to enhance the c++ messaging API in this way.
What do you mean by "supports non-blocking usage more effectively"? What
I would like to do, and what is more Ruby-ish, would be to call the
non-blocking version but provide a lambda function that can be called.
A more Ruby-like way would be to have Ruby _not_ pass :block => true to
the underlying implementation and, instead, require the user pass in a
lambda function. Then the API could spawn a Ruby thread, do the sync,
and then call the lambda function after it completes. So we never
_actually_ block the thread while the call runs. But we give the user a
means for knowing when the call finishes (which is what I assume is the
goal of the synchronous call since it returns no value).
That is the right idea, but how do you wait for the underlying
non-blocking operation to complete? We need to add callbacks or futures
to the C++ non-blocking operations to do this. But a C++ callback may be
called in a non-ruby thread, I don't know what facilities ruby has to
resolve that. A future just moves the problem - when you call
future.wait() you'll block ruby again.
What I would like to do in the c++ API is have a better way to wait for
something of interest to happen on a connection (or even better on a set
of connections).
There would then also need to be a simple and efficient way to determine
what has actually happened (e.g. is it an incoming message on a session
associated with the connection, the availability of credit enabling
further publication on a session, the confirmation of status on a
particular transfer in either direction etc).
This second part might for example be the addition of a
Connection::nextSession() and Session::nextSender() that were analogous
to the Session::nextReceiver() call we already have. The 'settlement' of
transferred messages in either direction is currently exposed through
counters on unsettled sent and acknowledged messages.
The first part is really some sort of polling mechanism. It could
perhaps be driven off IO events since ultimately that is what will
trigger any higher level event of interest. Certainly it involves some
sort of EventMachine like interface.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
