Re: semget() returns EAGAIN?

["Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin" <cygwin@cygwin.com>]

> The number of parallel open pipes, for instance.  By default, 10
> worker threads handle the load and up to 62 processes can be handled
> in parallel.

Hmm, so it is not an OS-imposed restriction...  Then I don't understand why it wasn't made to "just work":
to create a thread per client until that works, without having to have any pre-set limits.  Fail only if
the thread creation cannot be done.

> Apart from that, the preferred way to use semaphores is to use POSIX
> semaphores, that is, sem_open and friends.

Well, that's not entirely up to me, the app is already using (quite stably!) SYSV semaphore _arrays_ so switching to POSIX
would require some porting (and intensive bug checking -- provided that the app is being used on thousands of hosts).
Besides, TBH it looks like the POSIX-devising people were smoking some kind of weed when coming up with sem_timedwait() using
_absolute_ timeouts!  That's way too insane.  They also tried to screw up SYSV sems by saying they get created not necessarily
initialized (what's the point?! it totally defeats the purpose!)  TG, by then many systems had already had them implemented
decently (reset to 0 upon inception), so that "clause" did not have any chance to actually realize.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple