From: Francis Cianfrocca <garbagecat10@...>
Date: 2006-05-22T21:13:43+09:00
Subject: Re: sysread changes behavior in the presence of threads?

------=_Part_197263_19538205.1148300019711
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

No, I'm going for something rather different, and it has nothing to do with
Ruby. (And therefore, the point is a threadjack so I'll be brief.) Threads
are too difficult to use. Even if you have a lot of experience (I've been
programming posix-like threads since Solaris 2.4 and Win32 threads even
longer), concurrency within a process is darned hard to get right. One
really good reason to use threads is to capture system latencies like disk
and network i/o, but this can generally be done with events. Another good
reason is to reflect the structure of the problem you're trying to solve: i=
f
your problem really does involve multiple, independent control flows, then
threading the app will probably make it easier to write (but may also make
it slower and harder to scale). With teams I manage, when it's necessary to
use threads, I impose strict rules on when and how to apply mutexes, and ho=
w
to design synchronization sets. As long as my rules are followed, you
generally won't see a deadlock, and you will rarely see severe mutex
contention. But most programmers hate following them. (Among them: NEVER
call a function under lock, not even one you wrote, not even an inline or a
macro. Only variable reads and writes are allowed.)

Your second point: interactions between Ruby and native threads has nothing
to with nonblocking I/O. Separate problem, it was my mistake if I left the
implication that they are linked. I was thinking it might be possible to
teach Ruby to work with native mutexes and condvars.

On 5/22/06, Sam Roberts <sroberts@uniserve.com> wrote:
>
> 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
>
>
>

------=_Part_197263_19538205.1148300019711--