Threads and database access

Greetings.

I’m developing a TCP server that serves multiple
clients by multiplexing the input using
Kernel::select. I chose not to use threads because I
doubted my ability to synchronize everything properly.

Most of the data is stored in a (mySQL) database that
I access using DBI. However, as disk seeks are a slow
thing, I’m thinking of using a separate thread for
database reads/writes so that the server can go on
processing whatever it needs to process without
waiting for the database query to complete.

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?

Thanks,

mk

···

Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine’s Day
http://shopping.yahoo.com

ביום ראשון, 16 בפברואר 2003, 23:43, Matija Kejzar כתב:

Greetings.

Most of the data is stored in a (mySQL) database that
I access using DBI. However, as disk seeks are a slow
thing, I’m thinking of using a separate thread for
If SQL cross-compatibility is not an issue, Perhaps you should consider using
“INSERT DELAYED”, refer to the MySQL manual on this matter.

“…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”
Ruby threads are “green threads”, that is, they are managed by the interepter
itself(user-level threads) and not the OS(kernel-level threads)

That is, the C code section of Ruby checks once in a while if a context switch
is needed, however, this cannot be done while making a system call, so during
that time a thread context switch cannot occur.

nevertheless,syscalls are not supposed to take long time to complete, the
exception is I/O(which might block) but as I understand internally ruby
overcomes the matter in most cases using async I/O, or some other
technique(someone correct me here), at least in my experience.

Idan

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.

It may depend on the library you are using. I don't know about the mysql
client, but the ruby-oci8 library (for Oracle) lets you configure whether to
use the API in blocking or non-blocking mode, and says that unless you use
non-blocking mode, long queries will block other threads.

Regards,

Brian.

···

On Mon, Feb 17, 2003 at 08:43:39AM +0900, Matija Kejzar wrote:

"...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?