[Live-devel] filedescriptor leak on windows plateform

[Ross Finlayson]

>    // For some unknown reason, select() in Windoze sometimes fails with WSAEINVAL if
>    // it was called with no entries set in "readSet".  If this happens, ignore it:
>    if (err == WSAEINVAL && readSet.fd_count == 0) {
>      err = EINTR;
>      // To stop this from happening again, create a dummy socket:
>      int dummySocketNum = socket(AF_INET, SOCK_DGRAM, 0);
>      FD_SET((unsigned)dummySocketNum, &fReadSet);
>    }
>    if (err != EINTR) {
> #else
> 
> But the dummySocket is never closed.

Yeah, OK, in some future release I'll close "dummySocket" in the "BasicTaskScheduler" destructor.

Alternatively, because this code is Windows-specific (to work around a bug in Windows), you could use another OS.


> As during the lifetime of the process we can create/destroy many TaskScheduler, this small leak becomes important.

This (using a single, permanent process in which you repeatedly create objects, then destroy them all) is poor system design.  (Maybe there's something in your OS that requires you to design your system this way?  Even if so, that doesn't escape the fact that this is poor system design.  Helping people who design their systems this way is not a high priority for me.)


> Do you think it could be safe to add a close(dummySocketNum) ?

Definitely not (unless this is done only in the "BasicTaskScheduler"s destructor).  Having a closed socket in the select() 'read set' will lead to an 'invalid file descriptor' error.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20140526/6774973c/attachment.html>