[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

RE: [Libevent-users] Proper time to request port from a listener.



Please ignore this whole thing.  Sheesh, been too long since I've done low
level sockets stuff.  The end problem was a bit of sloppy code and me
misremembering an issue with Win32 specific servers that doesn't apply to
linux/osx.

> Hi Folks,
> 
> 	Maybe someone has done this before so figured I'd ask while I'm
> still experimenting with possible solutions.  In the process of finishing
> up
> some porting to OsX I noticed that I have a race condition in my code
> related to listener sockets.  Previously I would just bring up the
> listener
> socket, bind it, make it non-blocking, call accept once (dropping any
> success which should never happen anyway) and then query the port before
> moving on.
> 
> 	Now, with libevent I'm curious if there is a better method of doing
> this.  I started out just using the evconnlistener_new_bind but this is
> obviously not calling accept immediately on the socket since OsX is
> functional only if I insert a couple calls to libevent_loop into the code
> prior to requesting the bound port.  (NOTE: Win32 works fine but I assume
> that is because it calls AcceptEx immediately on the socket.)  In a single
> threaded system this is not a problem but much of this portion of my code
> is
> actually running in a worker thread owned by a multi-cast dns (i.e.
> bonjour/avahi) wrapper.
> 
> 	Currently my best guess is to go back to the old method and just use
> evconnlistener_new instead of the '_bind' variation passing in the socket
> after I've gotten the required information out of it.
> 
> 	Any suggestions are welcome.  Preferably in the future, listener
> might be able to do this fully asynchronously with an event callback or
> something and then it would all work without any extra front end work or
> portability issues.
> 

***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.