At 11:07 PM +0200 7/17/06, Rafael Garcia-Suarez wrote:
On 14/07/06, Artur Bergman <[EMAIL PROTECTED]> wrote:
>> If code is running in a thread or no doesn't mean it
should have to act differently.
I also think exiting from a thread is something that the
developer should be aware of is happening, and that is
why it is giving the warning.
That is what started off the whole discussion: Exiting from
a thread was NOT issuing a warning.
Then that should have been the fix.
I come to think that a better idea wrt exit() is one that was proposed
during the referred thread:
let exit() exit the application (like before), and add threads->exit()
to exit the thread. Opinions?
In light of the discussions again, I think that would make the most
sense, with one addendum: to have an easy way inside a thread to make
exit() to a threads->exit() instead. If you happen to have to use a
module (over which you have no control) inside a thread that might do
an exit(). And as the owner of the thread, you don't want it to exit
the application.
Trying to do this by override CORE::exit is not a option, as you can
only do this at compile time (as far as I know).
So I would favour in extra, cloned global variable that would be
checked by CORE::Exit, which would indicate whether to really exit(),
or do a threads->exit(). And have an easy way to change the (cloned)
setting of this variable with a threads class method, e.g.
thread->exit_exits_thread_only;
Liz