Re: CFWriteStreamCallback stops being called
Re: CFWriteStreamCallback stops being called
- Subject: Re: CFWriteStreamCallback stops being called
- From: "Marcelo Alves" <email@hidden>
- Date: Wed, 30 Jul 2008 12:24:19 -0300
2008/7/30 Liwei <email@hidden>:
> *Groans*
>
> How then do I check if the flag is set without polling? I thought the
> whole purpose of using run-loops is to be able to eliminate the need
> to poll something?
Sample code (not tested, and it uses NSStreams instead o CFStreams) :
-(void) write:(NSData *)data {
[self appendToBuffer:data];
[self writeBuffer];
}
-(void) writeBuffer {
if (streamIsAvailable) {
streamIsAvailable = false;
// write some data to the buffer
}
}
-(void) stream:(NSStream *)stream handleEvent:(NSStreamEvent)eventCode {
if (eventCode == NSStreamEventHasSpaceAvailable) {
streamIsAvailable = YES;
[self writeBuffer];
}
}
You don't need to really poll the CF/NSStream, just remember the
previous state.
And you can use NSLog to log your messages.
>
> (A side question, is there something in OSX that I can use to log my
> error messages? Something more native to OSX than stderr?)
>
> 2008/7/30 Marcelo Alves <email@hidden>:
>> I not sure if it works like NSStream but you will receive the
>> "stream can accept bytes" event just once after each write, not every
>> run loop iteration. So you will need a flag telling you the stream can
>> accept bytes but your buffer is empty.
>>
>> :: marcelo.alves
>>
>>
>> 2008/7/30 Liwei <email@hidden>:
>>> I've initialised a pair of read and write streams with
>>> CFStreamCreatePairWithSocketToHost() and put both of them in my main
>>> run-loop to respond to read and write events.
>>>
>>> The read stream callback basically retrieves and prints out any text
>>> it receives from the stream. It works perfectly.
>>>
>>> The write stream callback basically checks a buffer for any pending
>>> bytes to be written. If the event received is
>>> kCFStreamEventCanAcceptBytes and there are bytes to be written, it
>>> will write as much as it can using CFWriteStreamWrite(). This is what
>>> I'm having problems with.
>>>
>>> I've written a small for-loop to fill up the write buffer before I
>>> start the main run-loop (I thought the main run-loop is automatically
>>> started? I have to start it manually). When the run-loop starts, all
>>> the data from the buffer gets written and I can see the text coming
>>> out on the server side.
>>>
>>> Now, I add a run-loop timer to the code that writes to the buffer (I
>>> have implemented mutexes to prevent reading and writing to the buffer
>>> at the same time) every 5 seconds and recompile the code again. What I
>>> hope to see is that after the initial printout of text from the
>>> pre-filled buffer, I will get a printout every 5 seconds due to the
>>> timer.
>>>
>>> The problem is, other than the few printouts that occurred when the
>>> timer triggered when the application was still trying to empty the
>>> initial buffer, I do not get anything printed after that, even though
>>> the timer continues to trigger. I can see my buffer being filled up
>>> from 0 (after the initial clearing), but it stops being cleared.
>>>
>>> It appears that after the buffer is first emptied, the write stream
>>> callback stops being called. I've put in debug statements at all the
>>> points where I would explicitly remove the write stream from the
>>> run-loop, but none of them has been triggered.
>>>
>>> I've include statements that print out the status of the read and
>>> write streams in my run-loop timer as well, they show that both
>>> streams are still open.
>>>
>>> My read and write stream callbacks check for the
>>> kCFStreamEventErrorOccurred and kCFStreamEventEndEncountered events as
>>> well and none of them has occurred.
>>>
>>> So why does my callback stop getting called?
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Macnetworkprog mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>>
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden