[email protected] wrote:
> Hi Garrett,
>
> Garrett D'Amore wrote:
>
>> I've noticed a problem, which I think might be a bug. It causes some
>> grief for me with the Boomer project.
>>
>> Specifically, when a stream is opened as nonblocking (FNDELAY,
>> O_NONBLOCK, etc.), I find that I no longer get M_READ notifications,
>> even when I've asked for them using M_SETOPTS and SO_MREADON.
>>
>>
> I took a look at the code, and I agree with you (i.e., this looks like
> a bug).
> The M_READ message is only sent from within strwaitq(), but this is done
> after the check for FNDELAY/O_NONBLOCK. If FNDELAY is set, strwaitq()
> returns with EAGAIN before getting to the code that sends the M_READ.
> Of course, if there is already data at the stream head, strwaitq()
> doesn't get called.
> I suspect this code has worked this way for many years...
>
Yes, I saw the same. However, from what I can tell, MREAD is only ever
used (up til now) with the tty streams. So maybe for those, it doesn't
matter.
>> This causes problems, because I really don't want to start an audio
>> engine recording until the user application calls read(2). However,
>> without M_READ notification, I have no way to detect the point at which
>> the app calls read(2).
>>
>>
> I don't know enough about audio recording. If there is no data to record,
> shouldn't the engine simply block? In other words, why use FNDELAY
> in the first place?
>
Applications use FNDELAY with e.g. select(). I tend to agree its better
not to use FNDELAY if they can avoid it, but I'm stuck with the
application binaries that already exist and hence I can't fix them. :-(
(And changing applications might be "non-trivial", in this regard, even
if I could do so.)
-- Garrett
> max
>
>
> _______________________________________________
> opensolaris-code mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
>
_______________________________________________
networking-discuss mailing list
[email protected]
