ipc, sockets and windows sp2

[Vincent Dedun]

>> I just saw a strange stuff : in sysv_sem.cc (cygserver) at end of 
>> semop
>> function (:done2 label), the mutex is released after waking up waiting
>> process, shouldn't it be the inverse ?
>
> No, the mtx_unlock is correct.  If you're looking for bugs, they are 
> very
> likely in the bsd_* files in cygserver.  Even though the sysv_* files 
> taken
> from FreeBSD are not proved to be 100% correct, there's a high 
> probability
> that I produced the bug in some of the bsd emulation functions.  
> msleep is
> a good candidate, FWIW.
>
> Any active debugging or tracking down the bug is highly appreciated,
> probably not only by me.
>

there is a problem in bsd_mutex.cc I think.
the problems occurs as soon as msleep/wakeup stuffs are called, which 
means
msleep is never awaken by wakeup.

with previous testcase,
grepping cygserver debug output, show that, with 2 child process 
sharing mutex, wakeup is called first, then 2 msleep are called. So 
when msleep is called, wakeup has already been called, and msleep has 
to sleep forever.

this is a problem, as wakeup is called when another process is WAITING 
for the semaphore, and msleep is called when another process is LOCKING 
the semaphore.

a use of wakeup means another process called msleep before, so why 
seeing the first msleep after the only wakeup in the log ?

i don't have freebsd so i can't test this testcase on it, and i'm not 
sure if it relevant to sysv_sem.cc from bsd, or from bsd_mutex.cc not 
handling this as sysv_sem.cc expect it.

furthermore, when using 2 children and sleep(1) instead of usleep, show 
a strange behaviour, after a certain time (some seconds here), the 
semaphore get values like 6,9,10.. instead of 0,1.


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