https://issues.dlang.org/show_bug.cgi?id=3462

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh@quickfur.ath.cx

--

https://issues.dlang.org/show_bug.cgi?id=3462

--- Comment #7 from hsteoh@quickfur.ath.cx ---
This issue keeps cropping up from time to time.

Is it possible to use the C library's atexit() hook to do druntime cleanups, so
that people can just call std.c.stdlib.exit() and have it do the Right
Thing(tm)?

--

https://issues.dlang.org/show_bug.cgi?id=3462

--- Comment #8 from Sean Kelly <sean@invisibleduck.org> ---
That would work fine for a single-threaded program.  But when you call exit(0) in a multithreaded program, all shared data is left in an undefined state. Mutexes might still be locked, etc.  So it isn't safe to do basically any cleanup at that point without the risk of deadlock.  C gets around this problem because multithreading is outside the scope of the language definition, but we don't have that luxury.  If you simply want the program to halt without cleanup though, that's much easier.

--

https://issues.dlang.org/show_bug.cgi?id=3462

--- Comment #9 from hsteoh@quickfur.ath.cx ---
So basically we're screwed unless we invent a language-wide way of triggering threads to terminate asynchronously?

--

https://issues.dlang.org/show_bug.cgi?id=3462

--- Comment #10 from Sean Kelly <sean@invisibleduck.org> ---
If we assume that people are multithreading using std.concurrency we could send "terminate" messages to all running threads, similar to the OwnerTerminated message today.

Beyond that... we could maybe send a signal to all running threads on supporting platforms and have those signal handlers throw.  Throwing from a signal handler doesn't always work (it's not explicitly supported) but it does on some OSes.

The only other thing I can think of would be to build in some flag that threads voluntarily check periodically.  But it's just as easy to do this on a per-application basis.  There's really little value in building such a flag into Druntime.

--

https://issues.dlang.org/show_bug.cgi?id=3462

--- Comment #11 from hsteoh@quickfur.ath.cx ---
In that case perhaps the solution is just to assume user code uses std.concurrency and implement exit() according to how you describe it. If they don't use std.concurrency, they probably need to implement their own method of thread control anyway, and so they wouldn't (shouldn't!) be relying on Phobos to properly shutdown all threads. Of course, this must be documented in big bold letters (figuratively speaking) in the documention of the prospective exit() function.

I don't like the idea of throwing from a signal handler -- it's in OS-specific territory and will probably be very fragile and non-uniform across platforms. I remember deadalnix's trick of manipulating signal handler return addresses in order to actually perform the throw outside signal handler context, but this is Posix-specific and perhaps even Linux-specific, and there is no guarantee anything of that sort is even implementable across all platforms we support or will support in the future. Besides, it may not address the problem of shared resources and potential deadlocks at all, so it's not even a complete solution to begin with.

--

https://issues.dlang.org/show_bug.cgi?id=3462

Justin Whear <justin@economicmodeling.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |justin@economicmodeling.com

--

https://issues.dlang.org/show_bug.cgi?id=3462

Ketmar Dark <ketmar@ketmar.no-ip.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ketmar@ketmar.no-ip.org

--- Comment #12 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
Created attachment 1442
  --> https://issues.dlang.org/attachment.cgi?id=1442&action=edit
another version, slightly less sophisticated

adds ExitError which inherits Error (i intend it to be "catchable" with
catch(Throwable)), respects `rt_trapExceptions` flag and adds nothing to
std.process (throw your rocks at the door to exit! ;-).

--

https://issues.dlang.org/show_bug.cgi?id=3462

--- Comment #13 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
*** Issue 13554 has been marked as a duplicate of this issue. ***

--

https://issues.dlang.org/show_bug.cgi?id=3462

Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code@dawg.eu

--- Comment #14 from Martin Nowak <code@dawg.eu> ---
Plain old exit(EXIT_FAILURE) should just work.

--