Coping with errors in starting async compilations

Coping with errors in starting async compilations

[Eli Zaretskii]

Andrea,

Is comp-run-async-workers capable of coping with failures to launch a
sub-process due to stuff like insufficient resources?  For example,
Emacs on MS-Windows doesn't allow to start more than 31 sub-processes
(including network connections, so it could be less than that), so
what happens when comp-run-async-workers attempts to start another
sub-process and that fails with EAGAIN?  That should be handled like
reaching the limitation of comp-effective-async-max-jobs.  Perhaps it
already is?

Thanks.

Re: Coping with errors in starting async compilations

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

> Andrea,
>
> Is comp-run-async-workers capable of coping with failures to launch a
> sub-process due to stuff like insufficient resources?  For example,
> Emacs on MS-Windows doesn't allow to start more than 31 sub-processes
> (including network connections, so it could be less than that), so
> what happens when comp-run-async-workers attempts to start another
> sub-process and that fails with EAGAIN?  That should be handled like
> reaching the limitation of comp-effective-async-max-jobs.  Perhaps it
> already is?
>
> Thanks.

Hi Eli,

good point, this is not handled.  What should the intended behaivour we
want?  Restart new compilations failed with EAGAIN and wait to start new
one?

Thanks

  Andrea

Re: Coping with errors in starting async compilations

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 18 Oct 2021 08:44:41 +0000
> 
> > Is comp-run-async-workers capable of coping with failures to launch a
> > sub-process due to stuff like insufficient resources?  For example,
> > Emacs on MS-Windows doesn't allow to start more than 31 sub-processes
> > (including network connections, so it could be less than that), so
> > what happens when comp-run-async-workers attempts to start another
> > sub-process and that fails with EAGAIN?  That should be handled like
> > reaching the limitation of comp-effective-async-max-jobs.  Perhaps it
> > already is?
> >
> > Thanks.
> 
> Hi Eli,
> 
> good point, this is not handled.  What should the intended behaivour we
> want?  Restart new compilations failed with EAGAIN and wait to start new
> one?

Yes, just like you do when the number of running jobs reaches the
maximum allowed number: queue the rest for later execution.  IOW,
effectively behave like comp-effective-async-max-jobs was lowered.