I agree.  Thinking out loud...with a true 'native' threaded model I 
don't know if it would be a spectacular idea to be able to block all 
threads.  I've often wondered how Ruby 1.9 will implement 
Thread.critical, at all.  If it does attempt to, then maybe this 
suggestion (though aimed mostly at 1.8.6) might still be useful (if you 
don't mind the possible slowdown).  If not then yeah--probably not worth 
the hassle :)

Other suggestions of how ensure_uninterruptable might work (like 'this 
thread doesn't accept interruptions [thread_name.raise's] for awhile') 
seem like even worse ideas.

The benefit of having such a feature in the first place would be that 
you can 'nest' timeouts and other code that executes 
other_thread_name.raise, without some dangerous issues cropping up when 
two raises occur very close to the same time.  Or basically that you can 
execute other_thread_name.raise on more complex code without the 
drawbacks that might occur.

An example of this is if you nest two timeouts one within another, and 
one happens to expire when the other is not finished processing its 
ensure block.  This will possibly cause a 'random' exception to be 
raised on the origin thread later.  I guess basically currently the use 
of other_thread_name.raise is dangerous, this would help that.

Just my $.02
Thought welcome.
-Roger


Robert Klemme wrote:
> On 15.10.2007 18:45, Robert Klemme wrote:
>> all threads should be avoided.  If you need exclusive access to 
>> resources you need to proper synchronize on them.
> 
> I meant: in the light of the fact that native threads will come at a
> certain point in time.  Your suggested feature would make it
> unnecessarily complex and slow to use native threads (there would have
> to be regular synchronization on some hidden global lock, which defies
> the whole purpose of using (native) threads).
> 
>   robert
-- 
Posted via http://www.ruby-forum.com/.