Hi Laurent !
> On 18/03/2015 18:08, Didier Kryn wrote:
No, you must write to the pipe to detect it is broken. And you won't
try to write before you've got an event from the netlink. This event
will be lost.
On 18.03.2015 18:41, Laurent Bercot wrote:
I skim over that discussion (because I don't agree with the design)
Why?
Did you note my last two alternatives, unexpectedly both named #3?
... but specifically the last one "Netlink the Unix way"?
- uses private pipe for netlink and named pipe for hotplug helper
(with maximum of code sharing)
- should most likely do the flow of operation as you suggested
(as far I did understand you)
- except, I split of the pipe watcher / on demand startup code of the
conf parser / device operation into it's own thread (process), for
general code usability as a different applet for on demand pipe consumer
startup purposes
(you had that function as integral part of your netlink reader)
- and I'm currently going to split of that one-shot "xdev init" feature
from the xdev, creating an own applet / command for this, as you suggested
(extending functionality for even more general usage, as suggested by
Isaac, independent from the device management, and maybe modifiable in
it's operation by changing functions in a shell script)
So why do you still doubt about the design? ... because I moved some
code into it's own (small) helper thread?
I can't make any substantial comments, but here's a nitpick: if you
use an asynchronous event loop, your selector triggers - POLLHUP for
poll(), not sure if it's writability or exception for select()- as
soon as a pipe is broken.
This is what I expected, but the problem is, the question for this
arrived, and I can't find the location where this is documented.
Note that events can still be lost, because the pipe can be broken
while you're reading a message from the netlink, before you come
back to the selector; so the message you just read cannot be sent.
But that is a risk you have to take everytime you perform buffered IO,
there's no way around it.
Ok, what would you then do? Unbuffered I/O on the pipe, and then what?
... if that single one more message dropped, except the others not read
from netlink buffer (to be lost on close), matters, then we shall indeed
use unbuffered I/O on the pipe, and only read a message, when there is
room for one more one more message in the pipe:
set non blocking I/O on stdout
establish netlink socket
loop:
poll for write on stdout possible, until available
(may set an upper timeout limit, failure on timeout)
poll for netlink read and still for write on stdout
if write ability drops
we are in serious trouble, failure
if netlink read possible
gather message from netlink
write message to stdout (should never block)
on EAGAIN, EINTR: do 3 write retries, then failure
... does that fit better? I don't think that it makes a big difference,
but I can live with the slight bigger code.
My problem is not the detection of the failing pipe write, but the
reaction on it. When that happen, the down chain of the pipe most likely
need more than just a restart. That is, it should only happen on serious
failure in the conf file or the device operations (-> manual action
required). So I expect more loss of event messages, than just that
single one message, you were grumbling about. Hence on hotplug restart
we need to re-trigger the plug events, nevertheless!
--
Harald
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
