[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dynamic loading progress

From: Eli Zaretskii
Subject: Re: Dynamic loading progress
Date: Sat, 21 Nov 2015 11:33:32 +0200

> From: Philipp Stephani <address@hidden>
> Date: Sat, 21 Nov 2015 09:19:48 +0000
> Cc: address@hidden, address@hidden, address@hidden
>     > Anyway, thanks for explaining this, I now know how to change the code
>     > to DTRT on MS-Windows wrt to the thread checks.
>     >
>     > This is unfortunately all surprisingly subtle and vaguely defined. See
>     e.g.
>     > http://stackoverflow.com/q/19744250/178761 (apparently the standards are
>     vague
>     > about what happens to detached threads after main has exited).
>     I don't see how that affects the issue at hand. The issue at hand is
>     whether a thread ID of the main thread could be reused while some of
>     the other threads belonging to the Emacs process are still running.
>     And the answer to that on MS-Windows is AFAIU a sound NO, because as
>     long as the Emacs process is alive, it holds a handle on the main
>     thread, which precludes the OS from discarding that thread's kernel
>     object. Why? because a thread handle can and is used to query the OS
>     about that thread's conditions, like its exit code, or wait for its
>     completion in the likes of WaitForSingleObject. So the kernel object
>     that represents the thread must be kept by the OS as long as at least
>     one open handle for the thread exists, and that prevents the OS from
>     reusing the thread ID.
> Does it actually hold that handle? It sounds reasonable, but I can't find it
> documented.

Not sure I understand what you are saying.  We create a handle, and
then never close it.  So it stays open for as long as the process
lives.  If some of the process's threads are still running, the
process is still alive, so the handle is not closed by the OS.

>     I don't think we want each of its callers call the signaling part by
>     itself. That would be repeating the problem with malloc itself: many
>     programs simply neglect to include the code which does TRT when it
>     returns NULL. xmalloc solves this, and makes sure the (non-trivial)
>     error action and message are always the same in that case.
>     We need a variant of this for memory allocated on behalf of modules, I
>     think.
> But this would require modules to be prepared for handling longjmps, which in
> general they aren't.

The jump should be in a module-friendly way, obviously.  IOW, it will
have to call (the moral equivalent of) module_non_local_exit_signal.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]