semget() returns EAGAIN?

semget() returns EAGAIN?

[Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin]

I'm noticing that in a high-contention situation (many processes try to get ahold of a semaphore) semget() on Cygwin starts to return EAGAIN (try again) after about 62 processes has gotten to call semget() and are actively competing for the semaphore (i.e. using the semaphore ID semget() returned to them).

EAGAIN is not documented in any of semget() API documentation that I can find.

I understand that in Cygwin semget() is implemented as a connection to cygserver, and the error probably stems from there, but I don't think that such a code is appropriate as a final errno.  And why is there a limit, to begin with?  What exactly imposes it?

--
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

Re: semget() returns EAGAIN?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]

On Aug  7 05:02, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote:
> I'm noticing that in a high-contention situation (many processes try
> to get ahold of a semaphore) semget() on Cygwin starts to return
> EAGAIN (try again) after about 62 processes has gotten to call
> semget() and are actively competing for the semaphore (i.e. using the
> semaphore ID semget() returned to them).
> 
> EAGAIN is not documented in any of semget() API documentation that I
> can find.
> 
> I understand that in Cygwin semget() is implemented as a connection to
> cygserver, and the error probably stems from there, but I don't think
> that such a code is appropriate as a final errno.  And why is there a
> limit, to begin with?  What exactly imposes it?

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.  If the numbers are too low in your scenario, try to
raise them in /etc/cygserver.conf.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: semget() returns EAGAIN?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]

On Aug  7 10:12, Corinna Vinschen wrote:
> On Aug  7 05:02, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote:
> > I'm noticing that in a high-contention situation (many processes try
> > to get ahold of a semaphore) semget() on Cygwin starts to return
> > EAGAIN (try again) after about 62 processes has gotten to call
> > semget() and are actively competing for the semaphore (i.e. using the
> > semaphore ID semget() returned to them).
> > 
> > EAGAIN is not documented in any of semget() API documentation that I
> > can find.
> > 
> > I understand that in Cygwin semget() is implemented as a connection to
> > cygserver, and the error probably stems from there, but I don't think
> > that such a code is appropriate as a final errno.  And why is there a
> > limit, to begin with?  What exactly imposes it?
> 
> 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.  If the numbers are too low in your scenario, try to
> raise them in /etc/cygserver.conf.

Apart from that, the preferred way to use semaphores is to use POSIX
semaphores, that is, sem_open and friends.  These don't require
cygserver.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: semget() returns EAGAIN?

[Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin]

> 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