Eli Zaretskii <
eliz@gnu.org> schrieb am Do., 18. Jan. 2018 um 16:23 Uhr:
> From: Philipp Stephani <p.stephani2@gmail.com>
> 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.