Re: OpenTransport behaviour under X
Re: OpenTransport behaviour under X
- Subject: Re: OpenTransport behaviour under X
- From: "Philip D. Wasson" <email@hidden>
- Date: Tue, 28 Oct 2003 14:39:25 -0500
On Monday, Oct 27, 2003, at 11:00 US/Eastern, Marc Stibane wrote:
I thought that OTLook was to poll for data event or to find out what
failed
in the case of an kOTLookErr and clear the endpoint for more usage.
That's the case if the code is running asynchronous. But my code is
running synchronous.
So, as I understand it, you don't have to call OTLook; you can
continue to
call OTRcv until you have no more data. Correct?
Yes, but then you get blocked if there is no data.
That's what OTLook is used for, find out whether there's data
available.
If not, the code wouldn't call OTRcv (which would block).
I'm pretty sure that the purpose of OTLook is not what you think it's
for. My impression is that OTLook returns the highest priority message
on the endpoint (and removes that message from the endpoint since
you've now seen it). It is not supposed to just tell you whether
there's unread data or not.
You could set your endpoint to be non-blocking and then you won't block
when you ask to read data that isn't there.
You can check the T_MORE flag parameter to see if there is more data
ready
to be collected.
True. But not even neccessary in my case, since OTCountDataBytes said 8
bytes and the code just wants to read 4 bytes, one after the other.
I don't think T_MORE is useful in all protocols and all situations;
don't count on it. I even remember being told not to rely on
OTCountDataBytes' result, probably because with deferred task time and
asynchronous operations going on, you can't be sure that someone didn't
add or remove data during or shortly after your call to
OTCountDataBytes. I expect that if you're only reading a given
endpoint's data from one thread, there will never be less data on the
endpoint than what OTCountDataBytes says until you read from it (but
there could be more).
----------------------------------------------------------------------
Philip D. Wasson pwasson at maned dot com
Software Engineer Managing Editor Inc.
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.