In working on the Ruby layer I've hit a serious road block. For any call that blocks on I/O (Session.synch :block => true) the Ruby bindings can _not_ wrap that call in a Ruby thread and have it run while the main application thread continues to run. So, even though we do this:
def sync(args = {}, &callback)
block = args[:block] || false
if block
# Spawn a thread to run the sync
Thread.new do
@session_impl.sync true
callback.call if callback
end
else
@sessimpl_impl.sync false
callback.call if callback
end
end
the call to Session.sync will still block the whole application until
the call completes.
In Ruby 1.9 we'll have other options to work with this since pthreads
will be available in the code. But, for now, we won't be able to use
_Ruby_ threads to work around this limitation.
So in thinking htis over, I see one of two paths to go down:
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.
2. Inform the developer that blocking calls will stop the application
until Ruby 1.9.
Thoughts?
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
pgp4Rbn6wy6Wc.pgp
Description: PGP signature
