Re: master 54b9213: Handle thread-signal towards the main thread (Bug#32502)

Re: master 54b9213: Handle thread-signal towards the main thread (Bug#32502)

[Glenn Morris]

Michael Albinus wrote:

> branch: master
> commit 54b92132e1ec16565d59d6d9f8ff8910f38843b2

This fails to build --without-threads.

   thread.c:883:20: error: 'THREAD_EVENT' undeclared

Ref eg https://hydra.nixos.org/build/80480372

Re: master 54b9213: Handle thread-signal towards the main thread (Bug#32502)

[Michael Albinus]

Glenn Morris <rgm@gnu.org> writes:

Hi Glenn,

>> branch: master
>> commit 54b92132e1ec16565d59d6d9f8ff8910f38843b2
>
> This fails to build --without-threads.
>
>    thread.c:883:20: error: 'THREAD_EVENT' undeclared

I've fixed this in master.

> Ref eg https://hydra.nixos.org/build/80480372

Hmm. Is it useful to configure --without-threads on hydra?

Best regards, Michael.

Re: master 54b9213: Handle thread-signal towards the main thread (Bug#32502)

[Glenn Morris]

Michael Albinus wrote:

> Hmm. Is it useful to configure --without-threads on hydra?

The "tarball" job is --without-all, the normal builds are, err, normal,
and the "coverage" job is with everything. I think this is a useful
spread to catch precisely this kind of issue.

Re: master 54b9213: Handle thread-signal towards the main thread (Bug#32502)

[Michael Albinus]

Glenn Morris <rgm@gnu.org> writes:

Hi Glenn,

> The "tarball" job is --without-all, the normal builds are, err, normal,
> and the "coverage" job is with everything. I think this is a useful
> spread to catch precisely this kind of issue.

Thanks, I didn't know this. Makes sense.

Best regards, Michael.

Re: master 54b9213: Handle thread-signal towards the main thread (Bug#32502)

[Stefan Monnier]

> Hmm. Is it useful to configure --without-threads on hydra?

BTW, in order to speed up adoption of threads in Elisp packages, it
would be very helpful to make all builds provide them (just like we do
for bignums).

Admittedly, I don't know of any equivalent to "mini-gmp.c" for threads,
so I'm just hoping someone has a brilliant idea.


        Stefan

Re: master 54b9213: Handle thread-signal towards the main thread (Bug#32502)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 06 Sep 2018 08:25:35 -0400
> 
> > Hmm. Is it useful to configure --without-threads on hydra?
> 
> BTW, in order to speed up adoption of threads in Elisp packages, it
> would be very helpful to make all builds provide them (just like we do
> for bignums).

They all do, AFAIK.  What platforms do you know of that don't?

Re: master 54b9213: Handle thread-signal towards the main thread (Bug#32502)

[Stefan Monnier]

>> > Hmm. Is it useful to configure --without-threads on hydra?
>> BTW, in order to speed up adoption of threads in Elisp packages, it
>> would be very helpful to make all builds provide them (just like we do
>> for bignums).
> They all do, AFAIK.

Cool, then let's remove --without-threads,


        Stefan

Re: master 54b9213: Handle thread-signal towards the main thread (Bug#32502)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 06 Sep 2018 10:32:46 -0400
> 
> >> > Hmm. Is it useful to configure --without-threads on hydra?
> >> BTW, in order to speed up adoption of threads in Elisp packages, it
> >> would be very helpful to make all builds provide them (just like we do
> >> for bignums).
> > They all do, AFAIK.
> 
> Cool, then let's remove --without-threads,

That's a separate issue.  AFAIU, this option exists for people who
don't want threads in Emacs even if they can be supported.

Re: master 54b9213: Handle thread-signal towards the main thread (Bug#32502)

[Stefan Monnier]

>> >> > Hmm. Is it useful to configure --without-threads on hydra?
>> >> BTW, in order to speed up adoption of threads in Elisp packages, it
>> >> would be very helpful to make all builds provide them (just like we do
>> >> for bignums).
>> > They all do, AFAIK.
>> Cool, then let's remove --without-threads,
> That's a separate issue.  AFAIU, this option exists for people who
> don't want threads in Emacs even if they can be supported.

Hmm... would people really be OK with --without-threads causing Gnus to
become unusable?


        Stefan

Re: master 54b9213: Handle thread-signal towards the main thread (Bug#32502)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Thu, 06 Sep 2018 15:52:21 -0400
> Cc: emacs-devel@gnu.org
> 
> >> Cool, then let's remove --without-threads,
> > That's a separate issue.  AFAIU, this option exists for people who
> > don't want threads in Emacs even if they can be supported.
> 
> Hmm... would people really be OK with --without-threads causing Gnus to
> become unusable?

If Gnus indeed is unusable without threads (I didn't know that), that
could be a bug in Gnus that should be fixed.

Re: master 54b9213: Handle thread-signal towards the main thread (Bug#32502)

[Stefan Monnier]

>> Hmm... would people really be OK with --without-threads causing Gnus to
>> become unusable?
> If Gnus indeed is unusable without threads (I didn't know that),

It's not the case (yet), but it would be helpful to treat such
a situation as a non-bug, so that Gnus can be modified to take advantage
of threads without having to worry about backward compatibility.

> that could be a bug in Gnus that should be fixed.

Yet we wouldn't consider it a bug in Calc if it doesn't work when we
build without bignums.  That's the difference between bignums and
threads currently, and the point of my original question is to ask
whether we could change this situation and decide that Emacs-27 will
always come with threads, just like it always comes with bignums.


        Stefan

Re: master 54b9213: Handle thread-signal towards the main thread (Bug#32502)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org
> Date: Fri, 07 Sep 2018 08:12:31 -0400
> 
> > that could be a bug in Gnus that should be fixed.
> 
> Yet we wouldn't consider it a bug in Calc if it doesn't work when we
> build without bignums.  That's the difference between bignums and
> threads currently, and the point of my original question is to ask
> whether we could change this situation and decide that Emacs-27 will
> always come with threads, just like it always comes with bignums.

That's a circular reasoning, because we didn't yet decide to have
threads be a required feature.

As for making that decision for Emacs 27: I'm not sure we have enough
experience yet to do that.  So far, only one serious application is
attempting to use threads, and that application is not yet on master.
We need more experience, IMO, before we are ready to make that
decision.

Re: master 54b9213: Handle thread-signal towards the main thread (Bug#32502)

[Stefan Monnier]

> That's a circular reasoning, because we didn't yet decide to have
> threads be a required feature.

It's not a circular reasoning.  It's just that the thread took a longish
walk in order to finally clarify what I wanted to stay from
the beginning.


        Stefan

Re: master 54b9213: Handle thread-signal towards the main thread (Bug#32502)

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
>> Date: Thu, 06 Sep 2018 15:52:21 -0400
>> Cc: emacs-devel@gnu.org
>> 
>> >> Cool, then let's remove --without-threads,
>> > That's a separate issue.  AFAIU, this option exists for people who
>> > don't want threads in Emacs even if they can be supported.
>> 
>> Hmm... would people really be OK with --without-threads causing Gnus to
>> become unusable?
>
> If Gnus indeed is unusable without threads (I didn't know that), that
> could be a bug in Gnus that should be fixed.

FWIW, my idea here (and someone else might get around to implementing
this before I do, so this might be meaningless) was to let each Gnus
server conduct each network access in its a separate thread. So not a
single "Gnus thread", nor even "one thread per server", but creating a
new thread for each server as it accesses the network, letting the
thread then return and die. So once we have a canonical check for thread
support, it wouldn't be hard to accommodate both situations.

Re: master 54b9213: Handle thread-signal towards the main thread (Bug#32502)

[Michael Albinus]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> So once we have a canonical check for thread
> support, it wouldn't be hard to accommodate both situations.

For the time being, I use in the feature/tramp-thread-safe branch:

--8<---------------cut here---------------start------------->8---
;; Threads have entered Emacs 26.1, `main-thread' in Emacs 27.1.  But
;; then, they might not exist when Emacs is configured
;; --without-threads.
(defconst tramp-compat-main-thread (bound-and-true-p main-thread)
  "The main thread of Emacs, if compiled --with-threads.")
--8<---------------cut here---------------end--------------->8---

It is nil when there is no (sufficient) thread support.

Best regards, Michael.

Re: master 54b9213: Handle thread-signal towards the main thread (Bug#32502)

[Eric Abrahamsen]

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

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> So once we have a canonical check for thread
>> support, it wouldn't be hard to accommodate both situations.
>
> For the time being, I use in the feature/tramp-thread-safe branch:
>
> ;; Threads have entered Emacs 26.1, `main-thread' in Emacs 27.1.  But
> ;; then, they might not exist when Emacs is configured
> ;; --without-threads.
> (defconst tramp-compat-main-thread (bound-and-true-p main-thread)
>   "The main thread of Emacs, if compiled --with-threads.")
>
> It is nil when there is no (sufficient) thread support.

Looks reasonable -- thanks!

Eric