From: KUBO Takehiro <kubo@...>
Date: 2003-07-03T13:00:00+09:00
Subject: Re: DBD::Oracle9 and non-blocking mode

Brian Candler <B.Candler@pobox.com> writes:

> On Wed, Jul 02, 2003 at 01:03:12PM +0900, KUBO Takehiro wrote:
>> > However, I wasn't particularly happy with this approach, so in the end I
>> > changed my application to run as multiple processes (in fact running under
>> > FastCGI, so Apache controls the number of processes which are spawned), each
>> > of which is a single thread so I don't care if OCI blocks.
>> 
>> Hmm. What approach you prefer?
>
> It just seemed to work faster when I had five separate processes doing
> Oracle queries, than one process with five threads.

My approach wastes time. Undoubtedly your prospect is correct in
theory. OCI lacks any notification method whether the OCI call is
finished or not. So I use polling as a last resort.

I have one idea:
  1. create a native thread per one connection by using OCI thread APIs.
  2. when executing a OCI call which may be blocked, request the
     associated native thread to execute it, then stop its ruby thread
     by calling rb_thread_stop().
  3. after OCI call is finished, the associated native thread wakes up
     the ruby thread by calling rb_thread_wakeup().
But I hadn't tested it. I don't know whether it works.

> Also, using
> Apache/Fastcgi gave me a ready-made mechanism for creating a pool of
> processes and automatically restarting them if one fails. Using threads I'd
> have to write my own thread manager to do that.

Thanks.

-- 
KUBO Takehiro