From: Sam Roberts <sroberts@...>
Date: 2006-05-22T15:43:56+09:00
Subject: Re: sysread changes behavior in the presence of threads?

Quoting garbagecat10@gmail.com, on Sun, May 21, 2006 at 09:45:38PM +0900:
> As far as threads are concerned: I'm one of those people who believe
> that threads are seriously overused and should be avoided, especially
> in high-performance applications. But occasionally if you're mixing

I understand the argument in general, but since ruby's "threads" aren't
actually threads, does it apply here? Ruby with multiple "threads" is
really just a single process with a nice application-level way of
invoking particular code when a particular socket descriptor is ready,
and having that code have some state.

This is pretty much what any (other) single-threaded unix app hanging
off of select would do, except state would be held explicitly in some
kind of data structure. In ruby the state is held in the lexical
state/closure/stack (not sure what to call it) of the ruby thread.

Is the overhead of a ruby thread too high, for some reason? Uses too
much memory, doesn't scale well across thousands of descriptors because
it uses select, something else...? I'm sure you are trying to avoid
ruby's select-based, non-blocking, io-multiplexing scheme (aka
"threads") for a good reason, I just don't see what the reason is yet.

> Ruby and native code, you may have threads in each. As long as Ruby's
> threads are green, this split will exist, and it would be nice to able
> to synchronize a Ruby thread with a native one.

Interaction between ruby and any other OS threads is a well known
problem, but xx_nonblock APIs in Socket doesn't seem like its going to
help that.

Sam