From: Michael Bruschkewitz <brusch2@...>
Date: 2003-02-18T02:45:42+09:00
Subject: Re: Threads and database access

> 
> Now, my question is: is it possible for a separate
> thread to handle database access? Here's what I'm
> concerned about. The Programming Ruby book states:
> 
> "...if some thread happens to make a call to the
> operating system that takes a long time to complete,
> all threads will hang until the interpreter gets
> control back"
> 
> So, I guess my question is, will a database read or
> write that is handled by a single thread cause all the
> other threads to hang too?

Yes. Ruby threads are not native but simulated by the interpreter 
itself, where the function ruby_thread_schedule() has the central 
waiting point, which is a select-call with timeout. Look into your OS's 
description of select to get a hint what is possible to wait for. For 
W2k, select can only wait for socket-events, or timeout (sleep). On 
unix, select is able to wait for any file descriptor, which gives more 
possibilities. I don't know which are used by Ruby because I'm currently 
working on W2k. (Next project will be Solaris, I hope.)

I think this throws a lot of stones into the way on Win-Boxes, and 
should be somehow changed in further Versions of Ruby. I currently made 
a regarding suggestion on rubygarden.org, but I'm not very experienced 
in Ruby. I've not analyzed the Ruby code very deeply because a lack of 
time and I'm possibly misleaded.

My current project faces the same problem, and my solution is an own 
extension, which implements WaitForMultipleObjects, Events, 
WaitableTimers, NamedPipes, and Tcp-Connections, possible further event 
based I/O will follow (Keyboard, slow files, Semaphores). So I've 
avoided Ruby-Threads and wrote my own event-handler.

For your problem, it may be possible to start an own process which 
handles the database access and the requests are made through an TCP-
Connection from the Ruby-Script. 

Michael B.