GNU bug report logs - #30106
Loading file /sources/emacs/lisp/emacs-lisp/ert.elc failed to provide feature `mod-test'

Previous Next

Full log

View this message in rfc822 format

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: phst <at> google.com, 30106 <at> debbugs.gnu.org
Subject: bug#30106: [PATCH 2/2] Fix module support if threads are disabled (Bug#30106)
Date: Thu, 18 Jan 2018 19:25:53 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> schrieb am Do., 18. Jan. 2018 um 16:23 Uhr:

> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > Date: Thu, 18 Jan 2018 14:23:03 +0000
> > Cc: phst <at> google.com, 30106 <at> 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.

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.