"Joachim Durchholz" <[EMAIL PROTECTED]>:
>
> Hmm... I think having a global facilities accessible to all processes
> has problems once a program turns into a subprocess. Programmers would
> have to make sure that no stray OS.Process.exit or OS.Process.success is
> left in that code.
I'm not sure what you mean by subprocess here. Another process won't be
affected by an exit call. Other threads sure will, but they are just that:
threads of control flow, sharing state and everything, not independent
entities.
> So what about charging the first ("main") thread with setting the exit
> code, and terminating the system when the last thread has exited?
While that may seem like an obvious answer, it does not work. First of
all, there isn't really a "main" thread. All threads are equal, and the VM
already spawns several threads on startup, most of which conceptually run
forever. Furthermore, relying on implicit exit would necessary require you
to know whether, say, a library that you are using spawns threads - which
violates abstraction. In addition, you would need to know exactly if and
when it gets loaded, which is fragile and basically breaks the idea of
lazy linking. And so on.
To avoid that, you either need a dedicated "main" function, whose
termination exits the program, or explicit exit calls. The latter can be
seen as a more flexible continuation-based form of the former.
- Andreas
_______________________________________________
alice-users mailing list
[email protected]
http://www.ps.uni-sb.de/mailman/listinfo/alice-users
