From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Sat, 21 Nov 2015 11:33:32 +0200 Message-ID: <83r3jj4ryr.fsf@gnu.org> References: <83k2ptq5t3.fsf@gnu.org> <87h9kxx60e.fsf@lifelogs.com> <877flswse5.fsf@lifelogs.com> <8737wgw7kf.fsf@lifelogs.com> <87io5bv1it.fsf@lifelogs.com> <87egfzuwca.fsf@lifelogs.com> <876118u6f2.fsf@lifelogs.com> <8737w3qero.fsf@lifelogs.com> <831tbn9g9j.fsf@gnu.org> <878u5upw7o.fsf@lifelogs.com> <83ziya8xph.fsf@gnu.org> <83y4du80xo.fsf@gnu.org> <837fld6lps.fsf@gnu.org> <83610w5o97.fsf@gnu.org> <83wptb4ung.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1448098445 4989 80.91.229.3 (21 Nov 2015 09:34:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Nov 2015 09:34:05 +0000 (UTC) Cc: aurelien.aptel+emacs@gmail.com, tzz@lifelogs.com, emacs-devel@gnu.org To: Philipp Stephani Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 21 10:33:55 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a04YK-0001wZ-2y for ged-emacs-devel@m.gmane.org; Sat, 21 Nov 2015 10:33:52 +0100 Original-Received: from localhost ([::1]:51623 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a04YJ-0004iK-Au for ged-emacs-devel@m.gmane.org; Sat, 21 Nov 2015 04:33:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56818) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a04YG-0004iE-45 for emacs-devel@gnu.org; Sat, 21 Nov 2015 04:33:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a04YC-0001gz-To for emacs-devel@gnu.org; Sat, 21 Nov 2015 04:33:48 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:51895) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a04YC-0001gk-Lk for emacs-devel@gnu.org; Sat, 21 Nov 2015 04:33:44 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NY500F00QTTM600@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Sat, 21 Nov 2015 11:33:43 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY500FW6RW6HQ80@a-mtaout23.012.net.il>; Sat, 21 Nov 2015 11:33:43 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:194933 Archived-At: > From: Philipp Stephani > Date: Sat, 21 Nov 2015 09:19:48 +0000 > Cc: tzz@lifelogs.com, aurelien.aptel+emacs@gmail.com, emacs-devel@gnu.org > > > 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.