DeviceFS call for a single USB read

I’d like to see a DeviceFS call for a single read from a USB bulk IN endpoint, so that the message boundaries are preserved. One call must return exactly one or zero USB messages. Blocking and padding should be specified as parameters to the call.

…provided you can specify a timeout so after X centiseconds it will set V and return. Otherwise, what happens if you are waiting on a byte that never arrives?

That’s exactly what blocking is about. It has to return one or zero USB messages.

No fractions, no multiples.

That’s exactly what blocking is about. It has to return one or zero USB messages.

? My interpretation of “blocking” is that if you ask for a USB message, it will return one – even if that means busy-waiting in a loop for seventeen days (or failing with an error/exception).

This is why non-blocking was a revelation. It wouldn’t be difficult if the return was zero or one to just “poll” the blocking device from time to time, however because it was a blocking device (as to a pollable one), asking for a response would wait – forever if necessary – for the required conditions to be met in order that a response be provided.
This, obviously, was mildly annoying in a single-tasking world (BBC MOS, DOS, etc) but considerably less acceptable in a multitasking system.

Ah, I see how you’ve construed my words. I suggested blocking should be a parameter to the call – therefore the call could be set to be blocking or non-blocking. You should have the choice. I didn’t expect to have to spell out that the “blocking” parameter could be set to either of two values.