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