From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.org
Subject: [Bug 95331] fcntl.2 + sigaction.2 + signal.7 need further
information about use of a SA_SIGINFO signal handler that uses si->si_fd
Date: Tue, 24 Mar 2015 12:37:32 +0000
Message-ID:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Return-path:
In-Reply-To:
Sender: linux-man-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
To: linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
List-Id: linux-man@vger.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=95331
--- Comment #5 from Jason Vas Dias ---
One cannot use poll() or select() either in this case, either, because
there seems to be no way of polling for POLLOUT without being
flooded with revents==POLLOUT|POLLERR poll() returns, regardless
of a timeout parameter of -1 (another undocumented fact about poll(2) ) .
So is it true that Linux really provides no way of waiting for
output to become possible on a PIPE file descriptor after a SIGPIPE
has been received on it (the last reader has closed its input pipe to our
output pipe) , so we want to wait for a new reader to open an input pipe?
I thought that was what SIGIO was meant to be for ?
Or is there some other mechanism ?
Yes, I know, I should be using UNIX sockets and accept(), but the real
application is required to use PIPEs, and the documentation suggests
it should be possible to wait for an event to be generated by the kernel
when a reader connects a new input FD to our output pipe.
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html