Hi,
On 06/13/2013 08:16 PM, Chris Dickens wrote:
> Hi,
>
> Here's the patch.
Thanks, I've just pushed a somewhat modified version to master, I made 2
changes:
1) Use F_SETFL rather then F_SETFD as according to the manpage for O_NONBLOCK,
F_SETFL should be used. I'm surprised it works with F_SETFD too...
2) First get the flags and then or in O_NONBLOCK, rather then overriding
whatever
was set with only O_NONBLOCK.
Can you please give the latest master a try on your setup and confirm that my
version
also fixes your issue?
Thanks & Regards,
Hans
>
> BTW, I was running RHEL6.4 with libudev 147-2.46.
>
> Regards,
> Chris
>
>
> On Thu, Jun 13, 2013 at 2:23 AM, Hans de Goede <hdego...@redhat.com
> <mailto:hdego...@redhat.com>> wrote:
>
> Hi,
>
>
> On 06/13/2013 12:10 AM, Chris Dickens wrote:
>
> Hi,
>
> I'm running the latest code from the master branch
> (__cf8a313b2cdb6a25f00730452aab91__30cac5c52b) and am in the process of
> converting my application to use hotplug functionality on Linux. When my
> application calls libusb_get_device_list(), it hangs forever.
>
> I have tracked the issue to the hotplug_poll() function. The call to
> udev_monitor_receive_device() blocks forever. Even though this documentation
> (http://www.freedesktop.org/__software/systemd/libudev/__libudev-udev-monitor.html#__udev-monitor-receive-device
>
> <http://www.freedesktop.org/software/systemd/libudev/libudev-udev-monitor.html#udev-monitor-receive-device>)
> specifies that it is non-blocking by default, I found this not to be the
> case. As such, the loop never exits. The call to receive_device blocks until
> there is actually udev activity, and it returns a non-NULL value when this
> happens. This prevents the loop in hotplug_poll() from ever exiting.
>
> Simply setting the udev_monitor_fd to non-blocking (fcntl with
> O_NONBLOCK) resolved this issue for me.
>
>
> Hmm, this is likely caused by you using an older version of libudev which
> did not set the fd
> to non-blocking by default.
>
> We do want to support such older versions, so thanks for testing this,
> and figuring out the fix!
>
> Since I don't have an environment to test this, can you please send a
> tested patch fixing this?
>
> Then I'll test it does not break anything with newer versions of libudev
> and push it to master.
>
> Thanks & Regards,
>
> Hans
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
>
>
>
> _______________________________________________
> libusbx-devel mailing list
> libusbx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libusbx-devel
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
