[prev in list] [next in list] [prev in thread] [next in thread] 

List:       libusb-devel
Subject:    Re: [libusb] Always POLLOUT on file descriptors
From:       Laszlo Papp <lpapp () kde ! org>
Date:       2020-08-08 3:18:38
Message-ID: CAOMwXhOJgZAAjsTwRpzn3=8k2OpxFXuincGmotHd+y4nJ4_1uQ () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Sat, Aug 8, 2020 at 4:13 AM Tim Roberts <timr@probo.com> wrote:

> On Aug 7, 2020, at 9:44 AM, Laszlo Papp <lpapp@kde.org> wrote:
> >
> > I am trying to use libusb in a simple polling main function, but it
> looks like the file descriptors are always getting POLLOUT in the revents
> member of the structure even if an incoming message is being triggered,
> i.e. for reading. Is this expected? Is there anything I am doing wrong?
>
> That's the way it works.  Timer timeouts and other special events fire as
> POLLIN, USB traffic is POLLOUT.  You need to be handling the USB events in
> order, so there's no reason to have some bypass others.
>

Hi Tim,

Thank you so much for your prompt reply. So, as I understand, this is
expected behavior even for an input bulk endpoint?

My confusion came from using poll earlier in serial port or ethernet
(socket) context. We used to get POLLIN set by poll in the revents member
when data was available for reading, not POLLOUT. So, usb works differently?


> —
> Tim Roberts, timr@probo.com
> Providenza & Boekelheide, Inc.
>
>
>
> _______________________________________________
> libusb-devel mailing list
> libusb-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>

[Attachment #5 (text/html)]

<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Sat, Aug 8, 2020 at 4:13 AM Tim Roberts &lt;<a \
href="mailto:timr@probo.com">timr@probo.com</a>&gt; wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">On Aug 7, 2020, at 9:44 AM, Laszlo Papp &lt;<a \
href="mailto:lpapp@kde.org" target="_blank">lpapp@kde.org</a>&gt; wrote:<br> &gt; \
<br> &gt; I am trying to use libusb in a simple polling main function, but it looks \
like the file descriptors are always getting POLLOUT in the revents member of the \
structure even if an incoming message is being triggered, i.e. for reading. Is this \
expected? Is there anything I am doing wrong?<br> <br>
That's the way it works.   Timer timeouts and other special events fire as POLLIN, \
USB traffic is POLLOUT.   You need to be handling the USB events in order, so there's \
no reason to have some bypass others.<br></blockquote><div><br></div><div>Hi \
Tim,</div><div><br></div><div>Thank you so much for your prompt reply. So, as I \
understand, this is expected behavior even for an input bulk \
endpoint?</div><div><br></div><div>My confusion came from using poll earlier in \
serial port or ethernet (socket) context. We used to get POLLIN set by poll in the \
revents member when data was available for reading, not POLLOUT. So, usb works \
differently?</div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px \
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> — <br>
Tim Roberts, <a href="mailto:timr@probo.com" target="_blank">timr@probo.com</a><br>
Providenza &amp; Boekelheide, Inc.<br>
<br>
<br>
<br>
_______________________________________________<br>
libusb-devel mailing list<br>
<a href="mailto:libusb-devel@lists.sourceforge.net" \
target="_blank">libusb-devel@lists.sourceforge.net</a><br> <a \
href="https://lists.sourceforge.net/lists/listinfo/libusb-devel" rel="noreferrer" \
target="_blank">https://lists.sourceforge.net/lists/listinfo/libusb-devel</a><br> \
</blockquote></div></div>





_______________________________________________
libusb-devel mailing list
libusb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic