On 06/29/2011 07:43 PM, Darryl L. Pierce wrote:
On Wed, Jun 29, 2011 at 04:58:36PM +0100, Gordon Sim wrote:
1. Create a C++ child class of Session (and other classes that have
blocking I/O) and, when a blocking call is made, wrap the call in a
native thread. Then have the native code invoke the lamda funtion, and
make that lamda a requirement for such a call.
I'm not too keen on this, it seems at best a short term fix...
I agree. I put that out that as one possible path, but it's too easily a
vector for Ruby-specific problems.
2. Inform the developer that blocking calls will stop the application
until Ruby 1.9.
Thoughts?
...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.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
