Bug 51202 - Be more clear that udev_monitor_receive_device() is non-blocking
Summary: Be more clear that udev_monitor_receive_device() is non-blocking
Status: RESOLVED FIXED
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: All All
: medium minor
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-18 04:37 UTC by Sam Thursfield
Modified: 2012-06-18 06:56 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Patch to fix doc for udev_monitor_receive_device() (1.49 KB, patch)
2012-06-18 04:40 UTC, Sam Thursfield
Details | Splinter Review
Cleaner patch (1.04 KB, patch)
2012-06-18 04:42 UTC, Sam Thursfield
Details | Splinter Review

Description Sam Thursfield 2012-06-18 04:37:57 UTC
Since v171, the socket used by udev-monitor is non-blocking.  From the code, I'm assuming it is considered an error to call the function if no data is avaiable.  It would help if the documentation was clearer about this.
Comment 1 Sam Thursfield 2012-06-18 04:40:19 UTC
Created attachment 63173 [details] [review]
Patch to fix doc for udev_monitor_receive_device()
Comment 2 Sam Thursfield 2012-06-18 04:42:36 UTC
Created attachment 63174 [details] [review]
Cleaner patch

Always proof-read patches before submitting
Comment 3 Kay Sievers 2012-06-18 06:56:02 UTC
+ * It is an error to call this function if there is no data available.
+ * The function will return #NULL in this case. You should monitor the
+ * file handle returned by udev_monitor_get_fd() to ensure data is available
+ * before calling. Note that the behaviour of this function changed in
+ * libudev 171. Code that assumes this function will block should be changed
+ * to use poll().

Hmm, it's not really an *error*, sure, also not very useful, but it just
returns EAGAIN and NULL.

Also users are free to change the flags of the file descriptor to blocking mode.

I added a sentence to explain that.

Thanks!


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.