[Issue 3462] Add a clean way to exit a process.

[d-bugmail--- via Digitalmars-d-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P2  |P4

--

[Issue 3462] Add a clean way to exit a process.

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

   Assignee|s...@invisibleduck.org  |alexandru.razva...@gmail.co
   ||m

--

[Issue 3462] Add a clean way to exit a process.

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||and...@erdani.com

--

[Issue 3462] Add a clean way to exit a process.

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu and...@erdani.com changed:

   What|Removed |Added

Version|2.035   |D2

--

[Issue 3462] Add a clean way to exit a process.

[via Digitalmars-d-bugs]

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

naptime naptimeentertainm...@gmail.com changed:

   What|Removed |Added

 CC||naptimeentertainment@gmail.
   ||com

--

[Issue 3462] Add a clean way to exit a process.

[via Digitalmars-d-bugs]

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

Jonathan M Davis issues.dl...@jmdavisprog.com changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #16 from Jonathan M Davis issues.dl...@jmdavisprog.com ---
Honestly, I think that this sort of thing should be left up to whatever program
wants to attempt it. It's _not_ possible to do in the general case, because
there's no way to tell all running threads to exit cleanly. They could be doing
_anything_, including just sitting forever in while(1) {}. The only way for
them to stop cleanly is to choose to stop cleanly. For that, we could signal
them in some way, and then they could choose to shut down, but that requires
that all threads have a common way of being signalled to shut down and that
they're paying attention to it. And I don't think that that works very well,
even if you assume that all threads are using std.concurrency (which is a big
assumption), because unless the threads specifically handles that exception
being thrown from receive, then who knows what they're going to do. It depends
entirely on what the code looks like. Heck, they could be using std.parallelism
rather than std.concurrency without even using core.thread.Thread directly and
still not be using std.concurrency's receive or receiveOnly.

If a program is written with the idea that each thread can be signalled to shut
down, then it becomes possible to tell all threads to shut down cleanly, but
the code has to be written with that in mind. I don't see how a standard
solution makes any sense for that - especially when you consider the high risk
that folks will misunderstand it and misuse it - especially if its usage is as
simple as exitCleanly() - and that's assuming that we can even do it in the
first place.

So, I say that we should just leave it up to programs to do this themselves.
There is no silver bullet here. And it's not like std.concurrency needs
something baked in to be able to do it in your program either. You can just
create your own message that your receive calls expect which indicates to a
thread that it should shut itself down. Then when you want to shut down, you
signal all threads with that message and let them shut down.

--

[Issue 3462] Add a clean way to exit a process.

[via Digitalmars-d-bugs]

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

Martin Nowak c...@dawg.eu changed:

   What|Removed |Added

 CC||c...@dawg.eu

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

--

[Issue 3462] Add a clean way to exit a process.

[via Digitalmars-d-bugs]

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

--- Comment #15 from hst...@quickfur.ath.cx ---
That skips any struct dtors that might be in scope, which could leak resources.

--

[Issue 3462] Add a clean way to exit a process.

[via Digitalmars-d-bugs]

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

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

--

[Issue 3462] Add a clean way to exit a process.

[via Digitalmars-d-bugs]

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

Ketmar Dark ket...@ketmar.no-ip.org changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--- Comment #12 from Ketmar Dark ket...@ketmar.no-ip.org ---
Created attachment 1442
  -- https://issues.dlang.org/attachment.cgi?id=1442action=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! ;-).

--

[Issue 3462] Add a clean way to exit a process.

[via Digitalmars-d-bugs]

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

--- Comment #10 from Sean Kelly s...@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.

--

[Issue 3462] Add a clean way to exit a process.

[via Digitalmars-d-bugs]

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

--- Comment #11 from hst...@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.

--

[Issue 3462] Add a clean way to exit a process.

[via Digitalmars-d-bugs]

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

Justin Whear jus...@economicmodeling.com changed:

   What|Removed |Added

 CC||jus...@economicmodeling.com

--

[Issue 3462] Add a clean way to exit a process.

[via Digitalmars-d-bugs]

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

--- Comment #8 from Sean Kelly s...@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.

--

[Issue 3462] Add a clean way to exit a process.

[via Digitalmars-d-bugs]

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

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

--

[Issue 3462] Add a clean way to exit a process.

[via Digitalmars-d-bugs]

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

--- Comment #7 from hst...@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)?

--

[Issue 3462] Add a clean way to exit a process.

[via Digitalmars-d-bugs]

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--

[Issue 3462] Add a clean way to exit a process.

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=3462



--- Comment #6 from Leandro Lucarella llu...@gmail.com 2010-07-20 17:33:30 
PDT ---
I'm not very familiar with the new threading model in D2, I'm mostly a D1 user,
so I can't really say.

Sorry and thanks to take the time to answer.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3462] Add a clean way to exit a process.

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=3462


Sean Kelly s...@invisibleduck.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED


--- Comment #3 from Sean Kelly s...@invisibleduck.org 2009-10-31 23:15:05 PDT 
---
This is tricky.  If multiple threads are running then the app has to either
forcibly terminate the threads or wait for them to complete.  Even trickier if
the ProcessExit exception isn't thrown from the main thread.  One could send a
signal to all executing threads, telling them to throw an exception except that
it isn't legal to throw an exception from a signal handler.

Sadly, I haven't come up with a way to do this that doesn't risk deadlocks or
other Bad Things from happening.  As far as I know, the easiest thing is still
to call cstdlib exit().  If a clean, safe option presents itself I'd gladly add
a Runtime.exit() routine.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3462] Add a clean way to exit a process.

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=3462



--- Comment #4 from Leandro Lucarella llu...@gmail.com 2009-11-01 10:37:39 
PST ---
Here is the NG discussion:

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=99876

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3462] Add a clean way to exit a process.

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=3462



--- Comment #1 from Leandro Lucarella llu...@gmail.com 2009-10-31 22:18:41 
PDT ---
Created an attachment (id=486)
phobos patch (against svn r1316)

BTW, you can apply the patches with:

path/to/repo/trunk$ patch -p1  patch

in the root directory of the svn repo.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3462] Add a clean way to exit a process.

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=3462



--- Comment #2 from Leandro Lucarella llu...@gmail.com 2009-10-31 22:26:43 
PDT ---
If this is accepted, I guess the discussion in this thread should be revised:

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=99432

Personally I think:


try {
// code
}
catch {
// code
}


Should be a shortcut to:


try {
// code
}
catch (Exception) {
// code
}


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---