On 05/11/2017 06:21 AM, Mike Snitzer wrote:
On Thu, May 11 2017 at 5:43am -0400,
Martin Wilck <mwilck@xxxxxxxx> wrote:
On Thu, 2017-05-11 at 11:39 +0200, Martin Wilck wrote:
On Tue, 2017-05-09 at 12:10 -0700, Andy Grover wrote:
From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
This is the very simple patch for polling on the
/dev/mapper/control
device. The select or poll function waits until any event happens
on
any
dm device since opening the /dev/mapper/control device. When select
or
poll returns the device as readable, we must close and reopen the
device
to wait for new dm events.
Why have you done it that way? Couldn't you just save the
dm_global_event_nr at the time poll() is called?
I should have read your patch 2/3 before posting ... but I'm still
missing why the counter can't simply be set at poll() time.
If you did that then you would have a race where:
1) userspace has recorded events prior to poll()
2) an event triggers an increment of dm_global_event_nr before userspace
calls poll()
3) then userspace calls poll() -- only to find that after poll() returns
multiple events have occurred.
Which implies missed handling of events.
But if I'm wrong I'm sure Andy or Mikulas will correct me.
I think getting one readiness notification for multiple events should be ok.
But, the semantics of poll(2) are level-triggered, meaning if a fd is
ready then it will stay ready through multiple invocations of poll()
until something is done to satisfy it (e.g. for a TCP socket, read()ing
all the available data). Therefore we can't make it "edge-triggered" by
auto-clearing - it has to be a separate action.
my 2c -- Regards -- Andy
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
