bug#63865: 29.0.90; call-process while owning the X selection hangs other processes

[Eli Zaretskii <eliz@gnu.org>]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: luangruo@yahoo.com,  63865@debbugs.gnu.org
> Date: Sat, 03 Jun 2023 09:10:02 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> If I'm implementing some package and I decide to use call-process for
> >> some long operation, then some user uses my package and it runs
> >> call-process, and they get bored while waiting and switch away from
> >> Emacs, they'll experience a hang in some other application.  That hang
> >> seems clearly undesirable!
> >
> > Then don't design the package such that call-process blocks Emacs for
> > prolonged periods of time.  Because this will annoy the users of Emacs
> > even before it will be seen by other applications that request X
> > selections.
> 
> Forget other packages: Emacs itself uses call-process in tons of places
> where it will run for prolonged periods of time!

Really?  "tons of places where it will run for prolonged periods of
time"? what is "prolonged period of time" for this purpose?  Aren't
you a tad exaggerating?

> Should we port all these instances away from using call-process to avoid
> this behavior?

There's no general answer to that, we should examine each case
separately.

> > call-process has its use cases, which are important, and we will not
> > deprecate it.
> >
> > You can easily emulate call-process with start-process if you need to
> > do so, so Emacs gives you both possibilities (and expects you to use
> > whatever is right in each case).
> 
> What use case does call-process have on Unix, which an emulation in
> terms of start-process would not also satisfy?

When the process returns quickly.  call-process is significantly
simpler to use than start-process+wait, so doing that when unnecessary
is a complication we shouldn't take.

Anyway, this kind of discussion doesn't belong in a bug report about X
selections.