Re: NSStream blocking behavior?

FROM : Michael Gardner
DATE : Sat May 10 22:12:05 2008

Responding to my own message here, but from looking at the 
CFWriteStreamWrite documentation, that function does have the 
semantics I was looking for (blocks until at least one byte has been 
written). I would assume that NSOutputStream's -write:maxLength: has 
the same behavior, though the docs don't specify this. Can anyone 
confirm?

Is anyone else doing networking the same way I'm planning to? Is there 
anything wrong with the following strategy?

-Put the reader and writer in their own threads
-Ignore events from the NSOutputStream and just do blocking writes
-Use -performSelector:onThread:withObject:waitUntilDone: to pass data 
to/from the main thread

-Michael

On May 8, 2008, at 12:00 PM, Michael Gardner wrote:

> Okay, then next question: what will happen if I call -
> write:maxLength: on an NSOutputStream without having received a 
> NSStreamEventHasSpaceAvailable event? Is is guaranteed to block 
> until it has written at least one byte (assuming we're not dealing 
> with a fixed-length stream that has reached its capacity)?
>
> I ask because, given that run-loop scheduling is not a guarantee 
> against blocking, I plan to put my NSOutputStream writing code in a 
> separate thread. It would be nice if I can ignore the stream events 
> entirely and just call -write:maxLength: whenever the thread 
> receives data to write, with something like:
>
> - (void)sendLine: (NSString*)line {
>     NSUInteger bytesWritten = 0;
>     NSUInteger bytesToWrite = [line lengthOfBytesUsingEncoding: 
> NSUTF8StringEncoding];
>     char const * bytes = [line UTF8String];
>     while (bytesWritten < bytesToWrite) {
>         NSInteger result = [outputStream write: bytes + bytesWritten 
> maxLength: bytesToWrite - bytesWritten];
>         if (result <= 0)
>             @throw [NSException exceptionWithName: @"WriterThreadException" 
> reason: @"Error writing to output stream" userInfo: nil];
>         bytesWritten += result;
>     }
> }
>
> I would then use -performSelector:onThread:withObject:waitUntilDone: 
> from my main thread to queue data for sendLine to write. Is this a 
> viable approach?
>
> -Michael
>
> On May 8, 2008, at 2:58 AM, Stefan Haller wrote:
>

>> Michael Ash <michael.<email_removed>> wrote:
>>

>>> NSStream matches the semantics of the UNIX read/write calls. In both
>>> cases, if you are informed that data or space is available, you can
>>> issue a read or write for an arbitrary amount of data and be
>>> guaranteed that it will not block.

>>
>> I would have thought so too, but the NSStream documentation seems to
>> disagree (this is from the "Stream Programming Guide for Cocoa"
>> document):
>>
>> : It should be pointed out that neither the polling nor run-loop
>> : scheduling approaches are airtight defenses against blocking. If 
>> the
>> : NSInputStream hasBytesAvailable method or the NSOutputStream
>> : hasSpaceAvailable method returns NO, it means in both cases that 
>> the
>> : stream definitely has no available bytes or space. However, if 
>> either
>> : of these methods returns YES, it can mean that there is available
>> : bytes or space or that the only way to find out is to attempt a 
>> read
>> : or a write operation (which could lead to a momentary block). The
>> : NSStreamEventHasBytesAvailable and NSStreamEventHasSpaceAvailable
>> : stream events have identical semantics.
>>
>> I'm not sure exactly what "momentary block" means here.
>>
>>
>> --
>> Stefan Haller
>> Ableton
>> http://www.ableton.com/
>> _______________________________________________
>>
>> Cocoa-dev mailing list (<email_removed>)
>>
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/cocoa-dev/gardnermj
>> %40gmail.com
>>
>> This email sent to <email_removed>

>