-1

I'm doing application for iPhone using C sockets. At some point I'm performing recvfrom on separate NSThread (which is blocking) and I dont know how to force this operation to "unblock" and exit from thread gracefully. Calling shutdown() or close() doesn't change anything, recvfrom still hangs. Is there any way to keep it as blocking socket and force it to close properly and exit from thread?

As I'm accused of not trying anything this is my piece of code which doesn't cause recvfrom to "unblock":

This is what i have right now:

- (void) stopScan
{
    NSLog(@"stopScan !!!");
    [activityIndicator stopAnimating];
    shutdown(broadcastSocket, SHUT_RDWR);
    close(broadcastSocket);
    [discoveryThread cancel];
    [discoveryThread release];
    discoveryThread = nil;
    [scanTimer invalidate];
    broadcastSocket = 0;
    scanTimer = nil;
}

Calling just only shutdown() or close() does not unblock either.

solgar
  • 4,312
  • 2
  • 26
  • 30

1 Answers1

1

Sounds like you haven't actually tried anything. Just close it. The recvfrom() will exit with an error.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • So to add something more to this question/answer it seems that I removed error checking code somehow and my application entered infinite loop with continuous calls of recvfrom and that caused other problems in different place in my application. – solgar Jun 15 '12 at 10:44
  • This answer is not only wrong but dangerous. In particular, a nasty race condition can happen: 1) The thread calling `rcvfrom` does not get scheduled. 2) You close the socket. 3) Another thread opens a new socket and gets the same descriptor. 4) The thread calling `rcvfrom` finally gets scheduled and reads from an unrelated network connection. *Boom* – David Schwartz May 21 '17 at 01:10
  • @DavidSchwartz I have no belief in that. By the time `recvfrom()` actually blocks in the kernel, it is blocking not just on a socket descriptor value but actual pointers and TBCs inside the kernel. The close/open would magically have to deallocate and reallocate all that using exactly the same addresses, and it would also have to do that without noticing that there was an existing user of the socket descriptor that needed an error code delivered to it. I would regard a kernel capable of all that as containing a major bug. – user207421 May 21 '17 at 02:13
  • @EJP You missed the point about the thread calling `rcvfrom` not getting scheduled. It can't block in the kernel until it's scheduled. At that point, all it knows is the integer descriptor which, under POSIX, is often guaranteed to be reused. – David Schwartz May 22 '17 at 11:59