At 6:38 AM -0700 7/18/06, Artur Bergman wrote:
On Jul 18, 2006, at 3:39 AM, Elizabeth Mattijsen wrote:
At 2:29 AM -0700 7/18/06, Artur Bergman wrote:
On Jul 18, 2006, at 2:15 AM, Elizabeth Mattijsen wrote:
At 2:07 AM -0700 7/18/06, Artur Bergman wrote:
On Jul 18, 2006, at 1:52 AM, Elizabeth Mattijsen wrote:
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;
You can use CORE::exit if you make sure you set it before you
load the external module.
True, but generally you just "use" code in your program, which
means the code is used by the main thread already, before you
start the thread.
Which is the reason I once wrote Thread::Use.
Liz
Eh,
if you use a module that changes CORE::exit before you use any
other module you are set to go.
Well, that's what the "threads" module should do then.
I disagree, the threads module shouldn't change process level
semantics per default.
That's not what I propose. It's just that I think "threads" should
make it easy to change the semantics on a per thread basis.
Seriously, a thread is not a process, a process is not a thread. Add
thread exit if you want, but exit should exit.
Unless, you as a developer, decides to use an external module that
does an exit(), and you want it to just exit the thread.
Liz
