bug#54245: 29.0.50; select usage in GNUstep

bug#54245: 29.0.50; select usage in GNUstep

[Lars Ingebrigtsen]

Paul noted in bug#32452 that:

---
I notice that Emacs's GNUstep code calls 'select'. For completeness this 
should be 'pselect' instead, so that Emacs never calls 'select'.
---

So that should be fixed.  (I open a new bug report, because that bug
report was already way too long.)


In GNU Emacs 29.0.50 (build 7, x86_64-pc-linux-gnu, GTK+ Version 3.24.31, cairo version 1.16.0)
 of 2022-02-25 built on giant
Repository revision: ca3858563c7ba8ee3caa82fbd2b7c386ea60c0d3
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12014000
System Description: Debian GNU/Linux bookworm/sid


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#54245: 29.0.50; select usage in GNUstep

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Paul noted in bug#32452 that:
>
> ---
> I notice that Emacs's GNUstep code calls 'select'. For completeness this 
> should be 'pselect' instead, so that Emacs never calls 'select'.
> ---

I guess it's this code:

- (void)fd_handler:(id)unused
/* --------------------------------------------------------------------------
     Check data waiting on file descriptors and terminate if so.
   -------------------------------------------------------------------------- */
{
[...]
          result = select (selfds[0]+1, &fds, NULL, NULL, NULL);
          if (result > 0 && read (selfds[0], &c, 1) == 1 && c == 'g')
	    waiting = 0;

nsterm.m uses pselect throughout otherwise, so I guess changing this to
pselect should be unproblematic, too?  Perhaps Alan has some comments;
added to the CCs.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#54245: 29.0.50; select usage in GNUstep

[Robert Pluim]

>>>>> On Fri, 04 Mar 2022 16:30:38 +0100, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Paul noted in bug#32452 that:

    Lars> ---
    Lars> I notice that Emacs's GNUstep code calls 'select'. For completeness this 
    Lars> should be 'pselect' instead, so that Emacs never calls 'select'.
    Lars> ---

    Lars> So that should be fixed.  (I open a new bug report, because that bug
    Lars> report was already way too long.)

Iʼve been running with the following for a whole two days with no ill
effects (and the resulting emacs binary does not contain any calls to
'select'). Last time I looked, emacs never seems to use the sigmask
parameter to 'pselect' anyway, so itʼs kind of a moot point.

diff --git a/src/nsterm.m b/src/nsterm.m
index 670f8971df..4eb32de654 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -5830,7 +5830,7 @@ - (void)fd_handler:(id)unused
           fd_set fds;
           FD_ZERO (&fds);
           FD_SET (selfds[0], &fds);
-          result = select (selfds[0]+1, &fds, NULL, NULL, NULL);
+          result = pselect (selfds[0]+1, &fds, NULL, NULL, NULL, NULL);
           if (result > 0 && read (selfds[0], &c, 1) == 1 && c == 'g')
 	    waiting = 0;
         }

Robert
-- 

bug#54245: 29.0.50; select usage in GNUstep

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Robert Pluim <rpluim@gmail.com> writes:

> Iʼve been running with the following for a whole two days with no ill
> effects (and the resulting emacs binary does not contain any calls to
> 'select'). Last time I looked, emacs never seems to use the sigmask
> parameter to 'pselect' anyway, so itʼs kind of a moot point.
>
> diff --git a/src/nsterm.m b/src/nsterm.m
> index 670f8971df..4eb32de654 100644
> --- a/src/nsterm.m
> +++ b/src/nsterm.m
> @@ -5830,7 +5830,7 @@ - (void)fd_handler:(id)unused
>            fd_set fds;
>            FD_ZERO (&fds);
>            FD_SET (selfds[0], &fds);
> -          result = select (selfds[0]+1, &fds, NULL, NULL, NULL);
> +          result = pselect (selfds[0]+1, &fds, NULL, NULL, NULL, NULL);
>            if (result > 0 && read (selfds[0], &c, 1) == 1 && c == 'g')
>  	    waiting = 0;
>          }
>
> Robert

That LGTM, but I only tested on GNUstep.  The same code is also used on
macOS, so there might be some side effects.

Though the NS port is very old and I get the feeling that we keep
bumping into relics from over two decades ago, and using `select' might
very well be one of those.

Thanks.

bug#54245: 29.0.50; select usage in GNUstep

[Robert Pluim]

>>>>> On Sat, 05 Mar 2022 08:45:03 +0800, Po Lu <luangruo@yahoo.com> said:

    Po> That LGTM, but I only tested on GNUstep.  The same code is also used on
    Po> macOS, so there might be some side effects.

Iʼm on macOS

    Po> Though the NS port is very old and I get the feeling that we keep
    Po> bumping into relics from over two decades ago, and using `select' might
    Po> very well be one of those.

Every platform has a replacement for `select', but theyʼre all
different. The only real issue I see with (p)select is that you canʼt
wait on more than FD_SETSIZE descriptors.

Robert
-- 

bug#54245: 29.0.50; select usage in GNUstep

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

>     Po> That LGTM, but I only tested on GNUstep.  The same code is also used on
>     Po> macOS, so there might be some side effects.
>
> Iʼm on macOS

Thanks; I've pushed Robert's patch to Emacs 29 now, and I'm therefore
closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: bug#54245: 29.0.50; select usage in GNUstep

[Robert Pluim]

>>>>> On Sat, 05 Mar 2022 20:00:50 +0100, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Robert Pluim <rpluim@gmail.com> writes:
    Po> That LGTM, but I only tested on GNUstep.  The same code is also used on
    Po> macOS, so there might be some side effects.
    >> 
    >> Iʼm on macOS

    Lars> Thanks; I've pushed Robert's patch to Emacs 29 now, and I'm therefore
    Lars> closing this bug report.

I think this means we can now remove the checking for select in
configure, and the HAVE_SELECT define (I took a look, but then ran
into the w32 and msdos ports, and decided to stop :-) )

Robert
-- 

Re: bug#54245: 29.0.50; select usage in GNUstep

[Po Lu]

Robert Pluim <rpluim@gmail.com> writes:

> I think this means we can now remove the checking for select in
> configure, and the HAVE_SELECT define (I took a look, but then ran
> into the w32 and msdos ports, and decided to stop :-) )

AFAICT the MS-DOS port doesn't have select (unless you build it with X11
support, I think), so the define should stay.

nsterm.m used select regardless of the define anyway.

Re: bug#54245: 29.0.50; select usage in GNUstep

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> I think this means we can now remove the checking for select in
> configure, and the HAVE_SELECT define (I took a look, but then ran
> into the w32 and msdos ports, and decided to stop :-) )

I guess so -- perhaps Paul has some comments; added to the CCs.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: bug#54245: 29.0.50; select usage in GNUstep

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Mon, 14 Mar 2022 10:22:13 +0100
> Cc: Po Lu <luangruo@yahoo.com>, emacs-devel@gnu.org
> 
> >>>>> On Sat, 05 Mar 2022 20:00:50 +0100, Lars Ingebrigtsen <larsi@gnus.org> said:
> 
>     Lars> Robert Pluim <rpluim@gmail.com> writes:
>     Po> That LGTM, but I only tested on GNUstep.  The same code is also used on
>     Po> macOS, so there might be some side effects.
>     >> 
>     >> Iʼm on macOS
> 
>     Lars> Thanks; I've pushed Robert's patch to Emacs 29 now, and I'm therefore
>     Lars> closing this bug report.
> 
> I think this means we can now remove the checking for select in
> configure, and the HAVE_SELECT define (I took a look, but then ran
> into the w32 and msdos ports, and decided to stop :-) )

If that's your problem, you could convert HAVE_SELECT into DOS_NT, I
think.

The HAVE_SELECT in msdos.c is for the (old and quite defunct) MSDOS
build with Xlib (yes, there was such a beast: see those HAVE_X_WINDOWS
in msdos.c?), so IMNSHO we can simply drop HAVE_SELECT in msdos.c.

Re: bug#54245: 29.0.50; select usage in GNUstep

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  emacs-devel@gnu.org
> Date: Mon, 14 Mar 2022 17:30:00 +0800
> 
> Robert Pluim <rpluim@gmail.com> writes:
> 
> > I think this means we can now remove the checking for select in
> > configure, and the HAVE_SELECT define (I took a look, but then ran
> > into the w32 and msdos ports, and decided to stop :-) )
> 
> AFAICT the MS-DOS port doesn't have select

More accurately: the C library used by the MS-DOS port does have
'select', but it is not "good enough" for Emacs purposes, so we use a
separate Emacs-specific implementation in msdos.c.

Re: bug#54245: 29.0.50; select usage in GNUstep

[Stefan Monnier]

> The HAVE_SELECT in msdos.c is for the (old and quite defunct) MSDOS
> build with Xlib (yes, there was such a beast: see those HAVE_X_WINDOWS
> in msdos.c?),

OMG!  I remember seeing those HAVE_X_WINDOWS and taking for granted that
they were some weird left over from copy&paste.


        Stefan

Re: bug#54245: 29.0.50; select usage in GNUstep

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> The HAVE_SELECT in msdos.c is for the (old and quite defunct) MSDOS
> build with Xlib (yes, there was such a beast: see those HAVE_X_WINDOWS
> in msdos.c?), so IMNSHO we can simply drop HAVE_SELECT in msdos.c.

When I had the time a few weeks ago, I looked into resurrecting the X11
build on MS-DOS, but could not find any information about an Xlib
implementation for DJGPP.  So I can't help but wonder exactly what
enviroment that build once ran on.

I'd be indebted to anyone with that information.

Re: bug#54245: 29.0.50; select usage in GNUstep

[Robert Pluim]

>>>>> On Mon, 14 Mar 2022 15:10:09 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> I think this means we can now remove the checking for select in
    >> configure, and the HAVE_SELECT define (I took a look, but then ran
    >> into the w32 and msdos ports, and decided to stop :-) )

    Eli> If that's your problem, you could convert HAVE_SELECT into DOS_NT, I
    Eli> think.

Itʼs not really a problem, itʼs more "Is the issue serious enough to
potentially break builds for other people that I canʼt easily test"

    Eli> The HAVE_SELECT in msdos.c is for the (old and quite defunct) MSDOS
    Eli> build with Xlib (yes, there was such a beast: see those HAVE_X_WINDOWS
    Eli> in msdos.c?), so IMNSHO we can simply drop HAVE_SELECT in msdos.c.

Although this makes it sound like Iʼm worrying too much about
potential breakage.

Robert
-- 

Re: bug#54245: 29.0.50; select usage in GNUstep

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Robert Pluim <rpluim@gmail.com>,  luangruo@yahoo.com,  larsi@gnus.org,
>   emacs-devel@gnu.org
> Date: Mon, 14 Mar 2022 09:20:04 -0400
> 
> > The HAVE_SELECT in msdos.c is for the (old and quite defunct) MSDOS
> > build with Xlib (yes, there was such a beast: see those HAVE_X_WINDOWS
> > in msdos.c?),
> 
> OMG!  I remember seeing those HAVE_X_WINDOWS and taking for granted that
> they were some weird left over from copy&paste.

Not copy/paste at all.  See msdos/sed*x.inp and config.bat, where it
supports the --with-x option.

Re: bug#54245: 29.0.50; select usage in GNUstep

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Robert Pluim <rpluim@gmail.com>,  larsi@gnus.org,  emacs-devel@gnu.org
> Date: Mon, 14 Mar 2022 21:34:02 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The HAVE_SELECT in msdos.c is for the (old and quite defunct) MSDOS
> > build with Xlib (yes, there was such a beast: see those HAVE_X_WINDOWS
> > in msdos.c?), so IMNSHO we can simply drop HAVE_SELECT in msdos.c.
> 
> When I had the time a few weeks ago, I looked into resurrecting the X11
> build on MS-DOS, but could not find any information about an Xlib
> implementation for DJGPP.  So I can't help but wonder exactly what
> enviroment that build once ran on.
> 
> I'd be indebted to anyone with that information.

The environment was DesqView/X.  It came with a tailored version of
Xlib and other X libraries/utilities that ran on plain MS-DOS using (I
think) the DesqView's own QEMM DOS extender.  This was before DJGPP
v2.x was developed that uses DPMI to switch the processor into
protected mode and run 32-bit protected-mode code that uses virtual
memory.

That's all I know.  I never myself built such an Emacs, and never used
DesqView/X.  See https://en.wikipedia.org/wiki/DESQview for more.

Note that nowadays you'd need such an Xlib compiled with DJGPP v2.x,
which could run in the DPMI environment, so if DesqView/X is still
available somewhere, you will probably need to use QDPMI on plain
MS-DOS.  And if you run on plain MS-DOS, you'd have gazillion problems
with long file names that clash in the 8+3 namespace, because Emacs
stopped trying to be 8+3 clean long ago.

So resurrecting such a build would be a non-trivial project.