Re: Closing CFWriteStreams (re-sent)
Re: Closing CFWriteStreams (re-sent)
- Subject: Re: Closing CFWriteStreams (re-sent)
- From: Eli Bach <email@hidden>
- Date: Thu, 19 Jun 2008 22:15:40 -0700
On Jun 19, 2008, at 9:18 PM, Terry Lambert wrote:
On Jun 19, 2008, at 8:23 PM, Eli Bach wrote:
Terry,
First, I resent the message because I didn't receive the first one
from the list [and from way back, I expected to receive it].
I didn't complain about duplicate messages; however, realize that
this is a mailing list, and you may have to wait days for an answer,
if any.
I just mentioned it, as Apple's mailing lists have a new [since I last
was subscribed to these lists] option that defaults to not send my
posts to the mailing list back to me. I know I may or may not get a
reply. Heck, this could be the wrong list for the question [maybe
Carbon-Dev is better]?
For the client, I use
CFStreamCreatePairWithSocketToHost()
CFReadStreamSetProperty(kCFStreamPropertyShouldCloseNativeSocket,
kCFBooleanTrue
CFWriteStreamSetProperty(kCFStreamPropertyShouldCloseNativeSocket,
kCFBooleanTrue
and the code picks up in the above outline at the same spot [and
the code is shared between client and server].
Right now, it seems that using CFWriteStreamClose(), then releasing
the stream with the above setup doesn't force the data stream to be
flushed.
I'll try switching 'kCFStreamPropertyShouldCloseNativeSocket' to
false, then get the socket and do a close() or shutdown() on the
socket explicitly. Of course, I hate the idea of needing to spin
off another thread just to call close() [as it should block waiting
for all the data to be sent, and would halt the runloop doing it
there].
You need someone more fluent in CF than me. My response was
specifically for data buffered in the socket, but not yet sent to
the other end. If the socket is async and it is not explicitly
shutdown, then you will potentially lose unbuffered sent data.
I actually can' imagine that the CFWriteStreamClose() would not
flush output data before the close returned. If the socket was
async, though, a real close (or the process exitting) won't be
blocked, if the socket is async.
Or is there another, better way to do this?
Personally, I'd follow the PDF example exactly. It looks to me like
it waits until everything has been sent.
-- Terry
I re-read the CFNetwork PDF, and I can't really follow the synchronous
CFWriteStream sample as it's well, synchronous. The Close() is
expected to be blocking, and should cause the data to be flushed. And
of course the read stream sample is asynchronous, but also doesn't
help with my specific situation, as there is no buffering involved [as
the API should send all the data, then when the other side does an
orderly disconnect, it passed the callback the remaining data, then
sends is a 'stream has no more data' message, where the code then
calls CFReadStreamClose().
I also searched Apple's sample code [cftpsample] and of course, it
also does a network stream read, and a file stream write, so I
wouldn't expect a problem there either.
Since I register for a 'streamclosed' message, I'll see if I get one
when I call writestreamclose() [and then release the streams].
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden