On Feb 2, 2010, at 10:56 AM, Richard Penwell wrote:
while (([inputStream streamStatus] & [outputStream streamStatus]) ==
NSStreamStatusOpening && [[NSRunLoop currentRunLoop]
runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]]);
There are a couple of problems here...
(1) That test of the stream's statuses looks wrong. NSStreamStatus is
an enumeration, not a bit-field type, so and'ing two values together
doesn't create a meaningful result. I think the test you want is
([inputStream streamStatus] == NSStreamStatusOpening || [outputStream
streamStatus] == NSStreamStatusOpening)
i.e. "wait until both streams are no longer opening".
(2) Running the runloop in default mode is quite dangerous, because
it'll be receiving and processing all kinds of activities like user
events, perform-after-delay calls, delegate calls from asynchronous
operations, etc. All of these will be running re-entrantly in the
middle of your open method, and this can cause really strange things
to happen. If you must crank the runloop this way, make up a custom
mode string and use that.
(3) At a higher level, it would be better to design your code so that
it didn't have blocking semantics. You're going against the grain of
the way Cocoa works here. In general, in an API like this, the 'open'
call should return immediately, with a later delegate call or
notification to let the client know when the status changes.
—Jens_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
