views:

772

answers:

2

I'm currently polling my CFReadStream for new data with CFReadStreamHasBytesAvailable.

(First, some background: I'm doing my own threading and I don't want/need to mess with runloop stuff, so the client callback stuff doesn't really apply here).

My question is: what are accepted practices for polling?

Apple's documentation on the subject doesn't seem too helpful.

They recommend to "do something else while you wait". I'm currently just doing something along the lines of:

while(!done)
{
  if(CFReadStreamHasBytesAvailable(readStream))
  {
    CFReadStreamRead(...) ... bla bla bla
  } else {
    usleep(3600); // I made this up
    sched_yield(); // also made this up
    continue;
  }
}

Is the usleep and the sched_yield "good enough"? In there a "good" number to sleep for in usleep?

(Also: yes, because this is running in my own thread, I could just block on CFReadStreamRead - which would be great but I'm also trying to snag upload progress as well as download progress, so blocking there wouldn't help...).

Any insight would be much appreciated - thanks!

+3  A: 

I think this question is a bit of a paradox because you're asking what the best practices are for doing something that's intrinsically not a best practice ;)

When there's a perfectly good method for blocking on network I/O, any compromise that causes you to poll instead is by definition not the best practice.

That said, if you do poll I think it might be more appropriate to "run the runloop until date" on your thread, instead of using whatever posix sleep or yield method you're imagining. Remember that each thread gets its own runloop, so essentially by running the runloop you're allowing Apple to employ its concept of best practices for blocking until a future date.

As for the time delay, I don't know if you'll get a definitive answer for what a good time is. It's a tradeoff between peppering the CPU with polling cycles vs. being stuck in the runloop for a little while when I/O is ready to be read from the network.

Ideally I think I would refocus your efforts on making this work using I/O blocking calls, but if you stick with the poll & idle technique, don't fret too much about the specific delay time. Just pick something that works and doesn't seem to impact performance negatively in either direction.

(Also, I'd like to clarify that I'm not too religious about the polling vs. blocking thing, I'm only stressing its value because you're obviously in search of an elevated solution).

danielpunkass
You're certainly not wrong :). I'm using plain, ol' threads, no runloops associated with them. I figured I'd avoid the overhead of a runloop (negligible?). I also figured polling was going to happen at some level in the system, so I might as well do it myself - though I might be wrong about that.
atebits
I think you are wrong about the presumption that polling will happen at some lovel in the system.The way the runloop-based CFStream stuff works is at some point where the network I/O is actually being waited on, it literally becomes a hardware-driven wakeup. So there's no polling, just waiting.
danielpunkass
Yep, you're right. I suppose the best way to do this then is to use a runloop and schedule a timer to periodically check upload status. (Or use CFRunLoopRunInMode to force the runloop to hand back control to me periodically - overhead difference?).
atebits
Either way, the whole reason I'm doing this is completely up in smoke (unless I can come up with a fix). No way to accurately grab upload progress for small transfers: https://devforums.apple.com/thread/9352?tstart=0
atebits
+1  A: 

When doing manual CFStream based connections on a separate thread (for custom things like bandwidth monitoring and throttling), I use a combination of CFReadStreamScheduleWithRunLoop, CFRunLoopRunInMode and CFReadStreamSetClient. Basically I run for 0.25 seconds and then check stream status. The client callback also gets notified on its own as well. This allows me to periodically check read status and do some custom behavior but rely mostly on (stream) events.

static const CFOptionFlags kMyNetworkEvents =
kCFStreamEventOpenCompleted
| kCFStreamEventHasBytesAvailable
| kCFStreamEventEndEncountered
| kCFStreamEventErrorOccurred;

static void MyStreamCallBack(CFReadStreamRef readStream, CFStreamEventType type, void *clientCallBackInfo) {
    [(id)clientCallBackInfo _handleNetworkEvent:type];
}


- (void)connect {
  ...

  CFStreamClientContext streamContext = {0, self, NULL, NULL, NULL};
  BOOL success = CFReadStreamSetClient(readStream_, kMyNetworkEvents, MyStreamCallBack, &streamContext);


  CFReadStreamScheduleWithRunLoop(readStream_, CFRunLoopGetCurrent(), kCFRunLoopDefaultMode);

  if (!CFReadStreamOpen(readStream_)) {
    // Notify error
  }

  while(!cancelled_ && !finished_) {

    SInt32 result = CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.25, NO);

    if (result == kCFRunLoopRunStopped || result == kCFRunLoopRunFinished) {
      break;
    }

    if (([NSDate timeIntervalSinceReferenceDate] - lastRead_) > MyConnectionTimeout) {
      // Call timed out
      break;
    }

    // Also handle stream status CFStreamStatus status = CFReadStreamGetStatus(readStream_);
    if (![self _handleStreamStatus:status]) break;
  }

  CFRunLoopStop(CFRunLoopGetCurrent());


  CFReadStreamSetClient(readStream_, 0, NULL, NULL);
  CFReadStreamUnscheduleFromRunLoop(readStream_, CFRunLoopGetCurrent(), kCFRunLoopDefaultMode);

  CFReadStreamClose(readStream_);    

}


- (void)_handleNetworkEvent:(CFStreamEventType)type {
    switch(type) {
     case kCFStreamEventOpenCompleted:
      // Notify connected
      break;

     case kCFStreamEventHasBytesAvailable:
      [self _handleBytes];
      break;

     case kCFStreamEventErrorOccurred:
      [self _handleError];
      break;

     case kCFStreamEventEndEncountered:
      [self _handleBytes];
      [self _handleEnd];
      break;

     default:
       Debug(@"Received unexpected CFStream event (%d)", type);
      break;
    }
}
Gabe