Subject: bug#30106: [PATCH 2/2] Fix module support if threads are disabled (Bug#30106)

From: Philipp Stephani <[email-masked]>
Date: Thu, 18 Jan 2018 19:25:53 +0000

Eli Zaretskii <[email-masked]> schrieb am Do., 18. Jan. 2018 um 16:23 Uhr:

> > From: Philipp Stephani <[email-masked]>
> > Date: Thu, 18 Jan 2018 14:23:03 +0000
> > Cc: [email-masked], [email-masked]
> >
> >  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.