From: Jim Porter <jporterbugs@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: larsi@gnus.org, emacs-devel@gnu.org
Subject: Re: esh-proc test failures
Date: Tue, 23 Aug 2022 09:38:27 -0700 [thread overview]
Message-ID: <40db52f2-86f1-3e86-fbca-80a8be09ee66@gmail.com> (raw)
In-Reply-To: <83v8qj6iay.fsf@gnu.org>
On 8/23/2022 9:22 AM, Eli Zaretskii wrote:
>> Cc: larsi@gnus.org, emacs-devel@gnu.org
>> From: Jim Porter <jporterbugs@gmail.com>
>> Date: Tue, 23 Aug 2022 08:57:37 -0700
>>
>>> I don't think I follow. When the write fails, we get an error and
>>> propagate it all the way up to the caller.
>>
>> If we signal an error in a process filter, does Emacs inform the process
>> that wrote that data of the error? My tests showed that it didn't, but
>> maybe I was doing something wrong.
>
> Why are you talking about the process filter? Does that filter call
> process-send-string to write to the next process in the pipe? If so,
> it should inform Emacs about any errors in writing.
Yes. For the pipeline "foo | bar", the process filter for "foo"
(eventually) calls 'process-send-string' for "bar". The code in Eshell
is designed to do what you say.
The manual says, "If an error happens during execution of a filter
function, it is caught automatically, so that it doesn’t stop the
execution of whatever program was running when the filter function was
started." As I understand it, since we *want* to stop execution, that
means Eshell needs to be responsible for notifying "foo" if it failed to
write to "bar". Eshell does that by signaling a special error
('eshell-pipe-broken') when writing to "bar" after it terminated[1];
then, the process filter for "foo" can catch that and send a SIGPIPE
signal[2] to "foo".
>> The goal here is just to tell a process that the thing it's writing to
>> is gone, and that it should give up.
>
> That cannot happen, because Eshell is in-between. Instead, it is
> Emacs (Eshell) that should see the error, and deliver a signal to the
> relevant process if needed.
Then I think we're in agreement, since that's what Eshell currently
does. (My sentence above was just trying to say that, *somehow*, Eshell
needs to be sure that the relevant process is informed of the error.
Delivering a signal is how Eshell does it now, and I think that's ok.)
[1] That's the behavior in my new patch. Previously, it signaled
'eshell-pipe-broken' on any write error to "bar".
[2] Or some approximation of this on systems without SIGPIPE.
next prev parent reply other threads:[~2022-08-23 16:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <166036758418.2203.8730240669199078524@vcs2.savannah.gnu.org>
[not found] ` <20220813051305.6667BC09BFE@vcs2.savannah.gnu.org>
2022-08-14 18:06 ` esh-proc test failures Lars Ingebrigtsen
2022-08-14 18:44 ` Jim Porter
2022-08-22 17:06 ` Jim Porter
2022-08-22 18:56 ` Eli Zaretskii
2022-08-22 19:23 ` Jim Porter
2022-08-23 2:27 ` Eli Zaretskii
2022-08-23 3:53 ` Jim Porter
2022-08-23 11:37 ` Eli Zaretskii
2022-08-23 15:57 ` Jim Porter
2022-08-23 16:22 ` Eli Zaretskii
2022-08-23 16:38 ` Jim Porter [this message]
2022-08-30 3:18 ` Jim Porter
2022-08-30 16:51 ` Jim Porter
2022-08-30 20:56 ` Jim Porter
2022-08-31 20:52 ` Jim Porter
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40db52f2-86f1-3e86-fbca-80a8be09ee66@gmail.com \
--to=jporterbugs@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=larsi@gnus.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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).