Thread safety techniques for server applications?

On Aug 25, 4:15 pm, Aaron S. [email protected] wrote:

When relying on Rails, the rails handler has a mutex in it so that only

Posted viahttp://www.ruby-forum.com/.
The ‘Rails gateway’ is specific to a mongrel process - each process
has their own. Each process will handle one Rails thread.
For that reason you don’t have to worry about shared variables.
–Dave

Roger P. wrote:

I’m looking for some information about handling thread safety with Ruby.

Note also that sometimes if you are reading from TCPSockets the sockets
get confused and start reading from one another. To avoid this (I
think) use Francis C.'s EventMachine.

Possible ways to fix this might (might) be to ensure that every socket
read/write is ‘not at the same time as any other read/write’ (i.e.
surrounded by a mutex lock), or to perhaps write a drop in replacement
for the TCPSocket class that just uses EventMachine in the background
for I/O and queues the input/output.

I still haven’t ever found a fix for the problem of defining methods in
one thread and the methods are assigned to a different thread. I think
I may just report this one to ruby and forget about it.

Good luck all.
-Roger

Wow EventMachine works like a dream. Thank you!

In general, EventMachine encourages a style that doesn’t use threads at
all.
The I/O queueing you’re describing is already done by EM itself. All you
have to do is write the handlers and EM will call them itself as the I/O
comes in.

It may seem impossible to write network-aware programs without threads.
Not
only is it possible but it can have very real benefits.

On 10/8/07, Roger P. [email protected] wrote:

Possible ways to fix this might (might) be to ensure that every socket
read/write is ‘not at the same time as any other read/write’ (i.e.
surrounded by a mutex lock), or to perhaps write a drop in replacement
for the TCPSocket class that just uses EventMachine in the background
for I/O and queues the input/output.

In general, EventMachine encourages a style that doesn’t use threads at
all.
The I/O queueing you’re describing is already done by EM itself. All you
have to do is write the handlers and EM will call them itself as the I/O
comes in.

It may seem impossible to write network-aware programs without threads.
Not
only is it possible but it can have very real benefits.