"Bill Kelly" <billk / cts.com> schrieb im Newsbeitrag 
news:024d01c4bee4$5c87c880$6442a8c0 / musicbox...
> From: "Robert Klemme" <bob.news / gmx.net>
>>
>> >> >   while th = Thread::list.find {|t| t != Thread.current}
>> >> >     begin
>> >> >       th.join
>> >> >     rescue => e
>> >> >       warn{ e }
>> >> >     end
>> >> >   end
>>
>> But: this solution has a problem.  You can't ensure that it terminates. 
>> You
>> will have to set some kind of flag somewhere that no new threads are 
>> created
>> anyway.  *If* you do that, you can just as easily wait once for all
>> currently running threads *after* the flag has been set because you know
>> there will be no new threads.
>
> I did think about that, whether it would terminate... But I'd
> guessed that practically speaking the only scenario in which it
> wouldn't terminate is if the threads we're trying to join are
> themselves just spawning new threads like crazy.  Kind of like
> a fork() bomb, but with threads... :)
>
> I thought about making it fancier with raising our own
> Thread priority, and/or using Thread.critical... But I was
> guessing that in a reasonably well-behaved system, the liklihood
> of the above code not terminating was pretty much nil. . . .
> So I was betting we wouldn't need to worry about it.  Does it
> seem the above would be likely to not terminate outside of
> extreme cases like a "fork() bomb with threads" ?

Well, I don't know the rest of your application.  The crucial part is IMHO 
who creates all those threads.  In a common TCPServer situation where one 
thread just waits for a connection and then fires off a new thread for each 
session, you would want to make sure that this does not happen any more once 
the process should terminate (notified via a signal, a message via thread or 
whatever).  IMHO it's the cleanest solution to record this overall 
application state ("shutdown in progess") somewhere in order to react 
properly on this.  Once this has happened you only need to iterate and join 
once through all running threads and that's it.  It's the cleanest 
application design which does not leave any holes for bugs sneaking in when 
you install that application on another machine with other performance 
characteristics.  But as I said, it depends on your overall application 
architecture.

Kind regards

    robert