Re: CFStream bugs? (was Re: CFNetwork Website)
Re: CFStream bugs? (was Re: CFNetwork Website)
- Subject: Re: CFStream bugs? (was Re: CFNetwork Website)
- From: Tommy Knowlton <email@hidden>
- Date: Thu, 4 Jul 2002 14:18:43 -0600
Becky, I found the bug in the code I asked you about yesterday, if you
happen to read this before you reply to that one, please ignore it.
Thanks.
Please also see my questions re: the quoted message, inline below.
>
Date: Thu, 23 May 2002 10:06:03 -0700
>
Subject: Re: CFStream bugs? (was Re: CFNetwork Website)
>
From: Becky Willrich
>
In-Reply-To:
>
Message-Id: <email@hidden>
>
>
...
>
>
>> The [CFStream] API contained numerous bugs in Mac OS X 10.1.x.
>
>
>
> Does anyone know what the bugs are or their severity? If I were to
>
make my server program use them, are they inconveniences or major
>
crashers?
>
>
The short answer is that the bugs that have been fixed are serious, but
>
once you know they're there, they can all be worked around fairly
>
easily. Here's my understanding of the worst issues in 10.1.x and
>
their workarounds:
>
>
- A stream may invoke the client's event handler from within a call to
>
CFReadStreamRead/CFWriteStreamWrite. Workaround is for the client to
>
be prepared for re-entrancy. You can also SetClient(NULL) immediately
>
before calling Read/Write, then restore the client after the call
>
returns, but if you do this, you must check for end-of-stream and error
>
immediately after Read/Write returns - you will have lost the event.
Does this apply at all to CFReadStreamGetBuffer? I'm hoping to avoid
some of the copy cost of CFReadStreamRead, since I'm just turning around
and appending the new data bytes to an NSMutableData instance, and I'm
bound to pay a copy cost there anyway.
>
>
- CFReadStreamRead occasionally returns 0 when the stream is not
>
AtEnd. Workaround is just to check the stream's status if 0 has been
>
returned; the stream will correctly report its status as either AtEnd
>
or Open, depending on whether the stream has truly reached its end
>
>
- If CFReadStreamRead returns 0 or -1, occasionally the matching AtEnd
>
event or ErrorOccurred event is not sent. Workaround is to make sure
>
and properly field those return values.
>
>
- There is a race condition such that if you call CFReadStreamRead()
>
multiple times in response to a HasBytesAvailable event, you might get
>
another HasBytesAvailable event even though there are no further bytes
>
to be read. Workaround is to either always call CFReadStreamRead()
>
only once in response to kCFStreamEventHasBytesAvailable, or always
>
call CFReadStreamHasBytesAvailable() (which will correctly return TRUE
>
only if bytes are actually there) explicitly before calling
>
CFReadStreamRead().
again, how applicable are these bugs to CFReadStreamGetBuffer()?
>
...
>
>
Hope that helps,
>
REW
>
Thanks in advance
Kind regards,
--
Tommy Knowlton
_______________________________________________
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.