all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Philipp Stephani <p.stephani2@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Emacs developers <emacs-devel@gnu.org>
Subject: Re: master 2c79a8f 2/2: Use posix_spawn if possible.
Date: Tue, 29 Dec 2020 17:29:59 +0100	[thread overview]
Message-ID: <CAArVCkTe7uzapNzdi=mShvi2tMpySmUyQ482B6rbDgxix+UUEw@mail.gmail.com> (raw)
In-Reply-To: <83y2hklqhg.fsf@gnu.org>

(I'm still trying to set up some emulated Windows installation, but
haven't really been successful so far.)

Am Sa., 26. Dez. 2020 um 13:08 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
>
> But many of the breaking changes can be found by simple inspection.
> For example, in the case in point, if we are not going to use
> posix_spawn on MS-Windows, we need to augment nt/mingw-cfg.site and/or
> nt/gnulib-cfg.mk to avoid compiling the respective Gnulib modules,
> since doing that just risks causing trouble (as happened in this
> case).  Also, since you deduced (correctly) that the Gnulib
> posix_spawn module cannot be used on MS-Windows, it isn't enough to
> have a run-time condition for bypassing that, you need to #ifdef away
> the relevant code, because otherwise Emacs might fail to link for no
> good reason.

Gnulib provides a stub definition for posix_spawn on Windows as well
(in fact, as of a few days ago, it provides a non-stub
implementation), so linking shouldn't fail. Also compiling the stub
implementation on Windows shouldn't hurt; if it's never called the
linker will likely remove the stub.
What error messages do you see on Windows when trying to build the branch?

> > > Btw, regarding use of posix_spawn, I'd expect a discussion before we
> > > make such a change.  AFAIU it is not a trivial decision, as
> > > posix_spawn has its down sides, and therefore is not necessarily the
> > > best API for running sub-processes on every supported platform, even
> > > if you consider only the Posix ones.  We should consider the
> > > advantages and disadvantages before we make the decision.
> >
> > Sure, I'm happy to have that discussion. I briefly reviewed the
> > posix_spawn implementation of GNU libc and Gnulib, and found that it
> > uses vfork/clone + execve like our hand-rolled code, so I wouldn't
> > expect any significant change. The primary advantage is to offload
> > complexity into a library that can properly deal with system-specific
> > issues and can improve over time. For example, on Linux, posix_spawn
> > can use clone instead of vfork.
>
> See Savannah bug #59093 for one subtle issue:
>
>   https://savannah.gnu.org/bugs/?59093
>
> Since Emacs also sets its stack limit in some cases, this could be
> directly relevant to us.  (But I didn't look into it close enough to
> tell whether it actually is relevant.)

I think that specific problem isn't relevant (we don't change the
stack size between fork and exec), but the fix to
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24869 (ironically
reported by me) is.
As indicated in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24869#8,
it might be better to solve the underlying problem in a different way
that doesn't involve changing resource limits (changing a
process-global setting is somewhat fishy anyway, especially with
modules). Essentially we just need to make sure to not add file
descriptors larger than FD_SETSIZE to an fd_set.

>
> > On Windows, posix_spawn could directly call CreateProcess (though
> > Gnulib doesn't implement that yet).
>
> FYI: there's a general problem with using Gnulib code on MS-Windows
> for anything in Emacs that involves file names.  Emacs on MS-Windows
> uses UTF-8 encoded file names, which allows us to support 'char *'
> strings as file names outside of the domain of the current system
> codepage.  This works by basically wrapping any API that accepts file
> names with our own code that converts file names to UTF-16, and then
> invokes Windows APIs which accept 'wchar_t *' "wide" strings.  Gnulib
> doesn't have this feature, it just calls Windows APIs assuming the
> 'char *' strings as file names will be correctly interpreted -- which
> doesn't work with UTF-8 encoded file names.
>
> Running subprocesses definitely manipulates file names, so the above
> issue is very relevant here.

Agreed. It would be really nice if Gnulib adopted the Emacs approach
(probably hidden behind some flag).



  parent reply	other threads:[~2020-12-29 16:29 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-25 13:16 master 2c79a8f 2/2: Use posix_spawn if possible Eli Zaretskii
2020-12-26 11:26 ` Philipp Stephani
2020-12-26 12:08   ` Eli Zaretskii
2020-12-26 12:16     ` Eli Zaretskii
2020-12-29 16:43       ` Philipp Stephani
2020-12-31 16:24         ` Philipp Stephani
2020-12-31 16:39           ` Eli Zaretskii
2020-12-31 17:36             ` Philipp Stephani
2020-12-31 17:47               ` Eli Zaretskii
2020-12-31 20:24                 ` Philipp Stephani
2020-12-31 20:36                   ` Eli Zaretskii
2021-01-01  7:59                     ` martin rudalics
2021-01-01  8:04                       ` Eli Zaretskii
2021-01-01 23:38           ` Andy Moreton
2021-01-01 23:56             ` Alan Third
2021-01-02  1:12               ` Andy Moreton
2021-01-02  6:53                 ` Eli Zaretskii
2021-01-02  8:56                   ` Andreas Schwab
2021-10-29  9:46                     ` YAMAMOTO Mitsuharu
2021-10-30 18:30                       ` Alan Third
2021-11-02 19:58                         ` Alan Third
2021-11-02 20:15                           ` Eli Zaretskii
2021-11-02 20:36                             ` Alan Third
2021-11-03  3:24                               ` Eli Zaretskii
2021-11-10 12:42                                 ` Philipp Stephani
2021-11-10 14:10                                   ` Eli Zaretskii
2021-11-11 17:52                                     ` Philipp
2021-11-11 18:00                                       ` Eli Zaretskii
2021-11-11 21:04                                         ` Philipp
2020-12-29 16:29     ` Philipp Stephani [this message]
2020-12-29 18:15       ` Eli Zaretskii
2020-12-29 21:36         ` Philipp Stephani
2020-12-30  3:33           ` Eli Zaretskii
2020-12-31 16:10             ` Philipp Stephani
2020-12-31 18:33               ` Eli Zaretskii
2020-12-31 17:50       ` Philipp Stephani
2020-12-31 18:34         ` Eli Zaretskii
2020-12-31 20:14           ` Philipp Stephani
  -- strict thread matches above, loose matches on Subject: below --
2021-11-08 11:00 Aaron Jensen
2021-11-08 11:03 ` Aaron Jensen
2021-11-08 19:37 ` Alan Third
2021-11-09 14:46 ` Philipp
2021-11-09 15:57   ` Aaron Jensen
2021-11-09 17:05     ` Eli Zaretskii
2021-11-09 18:12       ` Aaron Jensen
2021-11-12 11:48         ` Philipp
2021-11-12 13:42           ` Aaron Jensen
2021-11-12 22:05             ` Alan Third
2021-11-13 14:08               ` Aaron Jensen
2021-11-13 16:03                 ` Philipp
2021-11-13 16:17                   ` Aaron Jensen
2021-11-15 15:01           ` Dmitry Gutov
2022-01-25  6:48 Saulius Menkevicius
2022-01-25  8:41 ` Eli Zaretskii
2022-01-25  8:58   ` Saulius Menkevicius
2022-01-25 11:46     ` Jostein Kjønigsen
2022-01-25 11:55       ` Po Lu
2022-01-25 12:22     ` Eli Zaretskii
2022-01-25 12:25       ` Saulius Menkevicius
2022-01-25 13:47         ` Eli Zaretskii
2022-01-28 17:12           ` Matt Armstrong
2022-01-29  8:03             ` Saulius Menkevičius
2022-01-29  8:26             ` Eli Zaretskii
2022-01-31 20:48               ` Saulius Menkevicius
2022-02-01  9:59                 ` Robert Pluim
2022-02-01 18:30                   ` Saulius Menkevicius
2022-02-01 19:23                     ` Robert Pluim
2022-02-01 19:52                       ` Eli Zaretskii
2022-02-02  8:30                         ` Robert Pluim
2022-02-02  8:54                           ` Saulius Menkevičius
2022-02-07 21:12                             ` Saulius Menkevicius
2022-02-08  8:27                               ` Robert Pluim
2022-02-08 12:12                               ` Eli Zaretskii
2022-02-08 12:18                                 ` Saulius Menkevicius
2022-02-08 14:59                                   ` Robert Pluim
2022-02-08 21:09                                     ` Saulius Menkevicius
2022-02-09  8:48                                       ` Robert Pluim
2022-02-12  8:44                                         ` Saulius Menkevicius
2022-02-12  8:59                                           ` Eli Zaretskii
2022-02-12  9:42                                             ` Saulius Menkevicius
2022-01-25 13:15 ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAArVCkTe7uzapNzdi=mShvi2tMpySmUyQ482B6rbDgxix+UUEw@mail.gmail.com' \
    --to=p.stephani2@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.