sockets - C++ select function breaks prematurely -

this question has answer here:

• breaking out socket select 4 answers

okay, first off: sorry if has been asked before, couldn't figure out correct keywords if had been.

situation: have small network server, runs in it's own thread. 'run'-method iterates on collection of active sockets (both udp , tcp), checks activity , it's thing. of achieved via select.

it possible, that, while 'stuck' in select new server added. purpose, have incorporated 'breaker socket', checked alongside others. gets closed when new socket added, new socket monitored traffic. (fd_set gets regenerated each time select got broken)

code (abbreviated):

fd_set fds; socket msock = breaker;  fd_zero(&fds); //aquire mutex if(breaker == invalid_socket)     msock = breaker = socket(af_inet, sock_stream, 0); fd_set(breaker, &fds); //iterate on active sockets , add them fds. //release mutex  if(select(msock + 1, &fds, null, null, null) > 0) {     //aquiremutex     //iterate on active sockets, check activity , act accordingly.     if(breaker != invalid_socket && fd_isset(breaker, &fds)         //close breaker , set invalid_socket     //release mutex } 

now actual problem: select broken continuously, no matter whether close breaker or not. reports 'activity' on socket.

breaker simple socket, not bound or connected. if change type of breaker 'dgram', doesn't break select @ all, if closed.

language c++, platform linux-derivate, invalid_socket defined -1 , socket typedef int. (code supposed work winsock too)

thank help.

edit: i've tried reading buffer. calling recv on breaker socket returned -1, setting errno 107 (transport endpoint not connected), not surprising, seeing how isn't connected.

edit: since intention apparently unclear, i'll describe again. possible, new server socket added queue @ given point in time. socket not monitored traffic, unless select broken (and fd_set subsequently refilled new socket) @ least once. traffic arriving on new socket thereby discarded.

i aware, using timeouts, hoping there'd different solution.

instead of using socket signal event use pipe (man 2 pipe).

i'd rather revise architecture if possible.

ps: swear haven't looked on question proposed michael burr in comment.