Brian Candler wrote:
>
> The alternatives aren't pretty: rewrite your application in an
> event-driven way (so you have to find a HTTP client library which works
> this way too), or fork off separate processes (which then have to
> communicate back to the central one with the results, which might mean
> select'ing across the children, or using the filesystem as a temporary
> data store)
An additional alternative that is pretty neat is combining an
event-driven library with Fibers in ruby 1.9.x.
Assuming of course, the existence of an HTTP library in that
idiom.
But I have a homegrown RPC library implemented using EventMachine,
which I recently adapted to use Fibers. So far, I am really
pleased with the result. It's like the best of both worlds.
My app is still single threaded, so I don't need any mutex /
synchronization / locking. But, I still get linear-style method
call semantics, in separate "parallel" execution Fibers. (In
essence the same sort of thing people have previously done with
continuation-based event libraries, only without the overhead of
continuations.)
So in any given fiber I can write pretty normal looking code,
like:
paths = @catalog.search("caption" => cap, "filename" => fname)
unless paths.empty?
title = "Search: #{str}"
doc_id = @window_svc.new_document_with_search_results(title, paths)
end
...and even though @catalog.search and @window_svc.new_document
may be making RPC calls to a remote host, only the current Fiber
will block waiting for the result.
I haven't used this technique long enough to have discovered if
there may be any pitfalls. But--so far--it's like the
convenience of threaded programming without the synchronization
issues.
Regards,
Bill