Conflict between socket_select() and system signals SIGUSR1, SIGUSR2?

Question

linux

Good afternoon, dear gurus, I urgently ask for your advice where to dig.
Armed with the article habrahabr.ru/post/134620 , I assembled a PHP daemon that quite successfully listens to system signals and everything was fine until the daemon needed to listen to sockets (for managers, the action log flies to the page in real time + commands for the daemon are received)
So the problem is not unambiguous:
individually, everything works, when the daemon does not work with sockets, it perfectly fulfills signals, and vice versa, the daemon works fine with sockets until there are signals.
But when signals start to go while working with sockets, the daemon can silently fall (without entries in the log and errors), and it can fall at an arbitrary iteration, i.e. the first 3 signals work out, and on 4 - a fall. Or the first 12 work out and falls again. Might fall on the first try.
Experimentally, it turned out that the daemon crashes on the socket_select() function.
Google is not helpful in solving the problem.
Wednesday: Ubuntu Server 12.04, PHP 5.4 with necessary modules like PCNTL
The daemon itself works with MySQL database and memcached + Frontend on Javascript WebSocket

Answer 1

And what for to you to process signals in general? This is ancient crap, which is best used to a minimum. I'm not at all sure that high-level languages ​​can handle the signal adequately. Well, that is, for example, in the signal handler, some object is created, with allocation in the heap, and at the time of malloc() another signal arrives, then it goes again to malloc() and deadlock can very easily come out, or a bunch of other things like where there is some kind of complex activity with locks or the capture of any resources in signal handlers.