Eli Zaretskii schrieb am Do., 18. Jan. 2018 um 16:23 Uhr: > > From: Philipp Stephani > > Date: Thu, 18 Jan 2018 14:23:03 +0000 > > Cc: phst@google.com, 30106@debbugs.gnu.org > > > > I'd prefer that the only file that calls systhread.c functions is > > thread.c; systhread.c is supposed to be low-level code concealed from > > application levels. So this would call for another level of > > indirection: add a new function to thread.c, and call that from > > emacs-module.c. > > > > Makes sense, I've moved in_current_thread to thread.c because it's > unrelated to modules. > > Thanks. > > > Otherwise, LGTM for master; thanks. > > > > Can we push this to emacs-26? Right now emacs-26 can't even be compiled > with --without-threads > > --with-modules (on some systems at least). > > How important is this? --with-modules is an opt-in switch, and the > default is to build with threads. So this sounds not very important > to me, and the change, although simple, is not really trivial, and > will affect any module. So I'm uneasy putting this on emacs-26, > especially since the Emacs 26.0.91 tarball is already ready and is > awaiting upload, so this will only go into the next pretest, which I > hoped could be a release candidate... > > Do you think leaving this for the next release will be so bad? > OK, pushed to master as 694ee38f8b. I don't expect this bug to cause correctness problems, even with the combination --without-threads --with-modules. The test is buggy, but it will only cause false positives with --module-assertions. That's annoying, but users can ignore these assertions. However, in the correct implementation, in_current_thread is effectively always true if threads are unavailable, so occasionally returning false is not a problem as far as modules are concerned.