On Thursday 11 September 2008 01:33:25 Robert Klemme wrote:
> On 11.09.2008 06:48, David Masover wrote:

> > The problem is, how do I detect a blocked thread, and execute some code 
when 
> > that happens?
> 
> Block on what?  IO?

Mostly, yes, but really any blocking operation. Could be a mutex. Could be a 
sleep call. Could be it was deliberately suspended.

In other words, anything that would cause Thread#stop? to return true.

> In that case you probably want to use more threads  
> as Ruby does handle this nicely.

Maybe not as nicely as I'd like, though -- I imagine 1.9's OS threads are 
heavier. And it presents problems with garbage-collection, with my current 
design.

> > The best I can think of is to poll, checking for #stop?, but that's 
hackish, 
> > and performance would be awful. Poll too often, and I burn CPU -- not 
often 
> > enough, and I end up with large windows of my app waiting for the poll 
thread 
> > to wake up.
> 
> I do not have a clear idea of your app

It's an actor library, which means apps will be written for it.
(Maybe. I might still drop it and just use Dramatis.)

> but usually with multiple threads  
> you use some form of synchronization (blocking queues, condition 
> variables etc.).

Right. An actor library is designed to abstract all of that away.

Let me phrase it differently -- it's like having a hundred thousand fibers 
that I want to execute at least once. I don't need to spawn a hundred 
thousand threads -- and I can't, I remember the limit being around three 
thousand in 1.9, and I really only need one or two.

But if one of those fibers blocks somewhere, I want to spawn another thread. 
Ideally, I need N + S threads, where N is the number of CPUs my program can 
use concurrently, and S is the number of other threads which are stopped.

That's oversimplifying a bit -- but if you want to know more, read about 
Erlang's process model. I'm trying to do something like that. The technical 
term for that is the "actor model".