Re: scratch/list-threads 833a2d4 2/9: Make lisp/thread.el the new home for thread-related Lisp functions

Re: scratch/list-threads 833a2d4 2/9: Make lisp/thread.el the new home for thread-related Lisp functions

[Michael Albinus]

gazally@runbox.com (Gemini Lasswell) writes:

Hi,

> branch: scratch/list-threads
> commit 833a2d41d07e3aa673ec5ab6f1d8ad1945bc5d0a
> Author: Gemini Lasswell <gazally@runbox.com>
> Commit: Gemini Lasswell <gazally@runbox.com>
>
>     Make lisp/thread.el the new home for thread-related Lisp functions
>     
>     * lisp/emacs-lisp/thread-list.el: Remove.
>     * lisp/emacs-lisp/thread.el: New file.

[...]

> -(provide 'thread-list)
> -;;; thread-list.el ends here
> +(provide 'thread)
> +;;; thread.el ends here

We have now src/thread.c and lisp/emacs-lisp/thread.el. The former
provides the feature `threads' (if Emacs is compiles with thread
support), the latter the feature `thread'.

Confusing.

Best regards, Michael.

Re: scratch/list-threads 833a2d4 2/9: Make lisp/thread.el the new home for thread-related Lisp functions

[Gemini Lasswell]

Michael Albinus <michael.albinus@gmx.de> writes:

> We have now src/thread.c and lisp/emacs-lisp/thread.el. The former
> provides the feature `threads' (if Emacs is compiles with thread
> support), the latter the feature `thread'.
>
> Confusing.

Hi Michael,

Other pairs of C and Lisp files share the same name without confusion,
so the confusing bit is the feature `threads' that thread.c provides.

That made me wonder why thread.c needs to provide `threads', so I looked
at the history of that file and found that you were the one who added it
(3744fda5fa), apparently in order to be able to skip tests if Emacs is
built --without-threads.

It seems to me that (bound-and-true-p main-thread) would work as a
substitute for (featurep 'threads) in the skip-unless forms in the
thread tests.  Can you think of a reason why it wouldn't?

Gemini

Re: scratch/list-threads 833a2d4 2/9: Make lisp/thread.el the new home for thread-related Lisp functions

[Michael Albinus]

Gemini Lasswell <gazally@runbox.com> writes:

> Hi Michael,

Hi Gemini,

> That made me wonder why thread.c needs to provide `threads', so I looked
> at the history of that file and found that you were the one who added it
> (3744fda5fa), apparently in order to be able to skip tests if Emacs is
> built --without-threads.

Yes, but not only for skipping tests. Everybody who implements something
based on threads shall have a simple mean to see, whether thread support
is configured for Emacs.

> It seems to me that (bound-and-true-p main-thread) would work as a
> substitute for (featurep 'threads) in the skip-unless forms in the
> thread tests.  Can you think of a reason why it wouldn't?

It would work, of course. But I'm a finicky German :-) `featurep' is the
default way in Emacs to check, whether a feature exist, so I've done it
this way.

Maybe we could do something similar to D-Bus support in Emacs: in
src/dbusbind.c the feature `dbusbind' is provided, and in dbus.el there
is the feature `dbus'. The former allows you to check, whether D-Bus
support has been configured for Emacs.

So we might provide the feature `threads-supported' or similar in
src/thread.c. WDYT?

> Gemini

Best regards, Michael.

Re: scratch/list-threads 833a2d4 2/9: Make lisp/thread.el the new home for thread-related Lisp functions

[Stefan Monnier]

> It would work, of course. But I'm a finicky German :-) `featurep' is the
> default way in Emacs to check, whether a feature exist, so I've done it
> this way.

Actually, fboundp is a much more common way to perform such tests,
especially since it can silence some warnings at the same occasion.
(featurep 'xemacs) is an important exception, tho.

> So we might provide the feature `threads-supported' or similar in
> src/thread.c. WDYT?

What's wrong with (fboundp 'make-thread)?


        Stefan

Re: scratch/list-threads 833a2d4 2/9: Make lisp/thread.el the new home for thread-related Lisp functions

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Actually, fboundp is a much more common way to perform such tests,
> especially since it can silence some warnings at the same occasion.

If we want to discourage the use of featurep, it shall be documented.
I, for example, regard it as natural way to test compatibility.

> (featurep 'xemacs) is an important exception, tho.

This test is not relevant anymore, isn't it?

> What's wrong with (fboundp 'make-thread)?

It returns t already for Emacs 26. If we go this way, (bound-and-true-p
main-thread) would be the better choice, as proposed by Gemini.

>         Stefan

Best regards, Michael.

Re: scratch/list-threads 833a2d4 2/9: Make lisp/thread.el the new home for thread-related Lisp functions

[Stefan Monnier]

>> Actually, fboundp is a much more common way to perform such tests,
>> especially since it can silence some warnings at the same occasion.
> If we want to discourage the use of featurep, it shall be documented.

I did not mean this to discourage its use.


        Stefan

Re: scratch/list-threads 833a2d4 2/9: Make lisp/thread.el the new home for thread-related Lisp functions

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 31 Aug 2018 09:19:58 -0400
> 
> What's wrong with (fboundp 'make-thread)?

That (AFAIK) it returns non-nil even when threads are not available?

Re: scratch/list-threads 833a2d4 2/9: Make lisp/thread.el the new home for thread-related Lisp functions

[Stefan Monnier]

>> What's wrong with (fboundp 'make-thread)?
> That (AFAIK) it returns non-nil even when threads are not available?

What is the reason for this?

Is it because we want to lazily try to load the relevant shared
library, so we don't know before the first call whether that shared
library is actually available?

> I could use then (configured-feature-p 'threads) in order to know
> whether Emacs has been configured --with-threads, explicitly or implicitly.

What if Emacs was configured --with-threads but at run-time the shared
lib is not available?
Maybe instead of

    (fboundp 'make-thread)

the better choice is

    (progn (ignore-errors (make-thread #'ignore)) t)

?


        Stefan

Re: scratch/list-threads 833a2d4 2/9: Make lisp/thread.el the new home for thread-related Lisp functions

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I could use then (configured-feature-p 'threads) in order to know
>> whether Emacs has been configured --with-threads, explicitly or implicitly.
>
> What if Emacs was configured --with-threads but at run-time the shared
> lib is not available?

It shall crash. That's what other programs do, too.

> Maybe instead of
>
>     (fboundp 'make-thread)
>
> the better choice is
>
>     (progn (ignore-errors (make-thread #'ignore)) t)
>
> ?

Too complicate. And, as said already, make-thread is not the function
I'm interested in. It exists in Emacs 26, and I need further threads
functionality introduced in Emacs 27.

>         Stefan

Best regards, Michael.

Re: scratch/list-threads 833a2d4 2/9: Make lisp/thread.el the new home for thread-related Lisp functions

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 03 Sep 2018 09:14:13 -0400
> 
> >> What's wrong with (fboundp 'make-thread)?
> > That (AFAIK) it returns non-nil even when threads are not available?
> 
> What is the reason for this?

AFAIR, that was how Tom wrote the code in the first place.  It makes
the configury slightly less complicated, and makes extending the
low-level support to other threading libraries slightly easier.  Not
very important reasons, but then we do have other features that just
do nothing useful on platforms where they cannot be supported.

> Is it because we want to lazily try to load the relevant shared
> library, so we don't know before the first call whether that shared
> library is actually available?

No.  AFAIK, all platforms that support threads either don't need any
library, or load it right at the beginning.

Re: scratch/list-threads 833a2d4 2/9: Make lisp/thread.el the new home for thread-related Lisp functions

[Stefan Monnier]

>> >> What's wrong with (fboundp 'make-thread)?
>> > That (AFAIK) it returns non-nil even when threads are not available?
>> What is the reason for this?
> AFAIR, that was how Tom wrote the code in the first place.  It makes
> the configury slightly less complicated, and makes extending the
> low-level support to other threading libraries slightly easier.  Not
> very important reasons, but then we do have other features that just
> do nothing useful on platforms where they cannot be supported.

Hmm... I see.  That's too bad: (fboundp 'make-thread) seems like the
most natural way to check for availability of threading.

> No.  AFAIK, all platforms that support threads either don't need any
> library, or load it right at the beginning.

That was my impression,


        Stefan

Re: scratch/list-threads 833a2d4 2/9: Make lisp/thread.el the new home for thread-related Lisp functions

[Gemini Lasswell]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Fri, 31 Aug 2018 09:19:58 -0400
>> 
>> What's wrong with (fboundp 'make-thread)?
>
> That (AFAIK) it returns non-nil even when threads are not available?

I just built Emacs configured --without-threads, and
(fboundp 'make-thread) returns nil.

On inspection of thread.c, the only Lisp symbols it creates if
THREADS_ENABLED is not defined are:

threadp
mutexp
condition-variable-p
main-thread

Re: scratch/list-threads 833a2d4 2/9: Make lisp/thread.el the new home for thread-related Lisp functions

[Eli Zaretskii]

> From: Gemini Lasswell <gazally@runbox.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
> Date: Wed, 05 Sep 2018 09:49:45 -0700
> 
> >> What's wrong with (fboundp 'make-thread)?
> >
> > That (AFAIK) it returns non-nil even when threads are not available?
> 
> I just built Emacs configured --without-threads, and
> (fboundp 'make-thread) returns nil.

Hmmm?...  Oh, yes: we don't call defsubr on the functions, although
the code is defined.  Somewhat silly, I'd say.

Re: scratch/list-threads 833a2d4 2/9: Make lisp/thread.el the new home for thread-related Lisp functions

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> It would work, of course. But I'm a finicky German :-) `featurep' is the
>> default way in Emacs to check, whether a feature exist, so I've done it
>> this way.
>
> Actually, fboundp is a much more common way to perform such tests,
> especially since it can silence some warnings at the same occasion.
> (featurep 'xemacs) is an important exception, tho.

Currently, we have `features', which gives us the feature symbols of
loaded packages. What we would need are the configured featurea of
Emacs. What about this:

--8<---------------cut here---------------start------------->8---
(defconst configured-features
  (mapcar
    (lambda (feat) (intern (downcase feat)))
    (split-string system-configuration-features))
  "A list of symbols which are the configured features of the executing Emacs.")

(defun configured-feature-p (feature)
  "Return t if Emacs is configured with FEATURE."
  (and (member feature configured-features) t))
--8<---------------cut here---------------end--------------->8---

I could use then (configured-feature-p 'threads) in order to know
whether Emacs has been configured --with-threads, explicitly or implicitly.

>         Stefan

Best regards, Michael.