Re: ipc, sockets and windows sp2

2005-04-09 Thread Corinna Vinschen
On Apr 9 11:40, Vincent Dedun wrote: > >What's the error code you get? > > read just return less byte than expected, and it occurs only in this > case. Ok, that's nothing to worry about and something you have to expect anyway. At least as long as the next attempt to read returns the missing da

Re: ipc, sockets and windows sp2

2005-04-09 Thread Vincent Dedun
There is a strange stuff, but it won't perturb me : when i run my master/slaves programs, then run the testcase at the same time and kill it, the slave may have a socket read error if it was reading on the socket at the same time that testcase is launched. I'm wondering if that's realy related or

Re: ipc, sockets and windows sp2

2005-04-09 Thread Corinna Vinschen
On Apr 9 10:55, [EMAIL PROTECTED] wrote: > It solves all my problems and nothing's left ;) Oh cool. What a relief. > There is a strange stuff, but it won't perturb me : > when i run my master/slaves programs, then run the testcase at the same > time and kill it, the slave may have a socket rea

Re: ipc, sockets and windows sp2

2005-04-09 Thread kraken+spam
it works for me too for the testcase i provided last time. But there is still some issues when you run several semaphore-using program at the same time. Again the thread synchronization was the culprit. I reworked it once again and I ran your testcase 5 times concurrently with different sleep val

Re: ipc, sockets and windows sp2

2005-04-08 Thread Corinna Vinschen
On Apr 8 17:10, [EMAIL PROTECTED] wrote: > it works for me too for the testcase i provided last time. > > But there is still some issues when you run several semaphore-using > program at the same time. [Insert swear-word here] > to reproduce it : > -compil last testcase with this modification

Re: ipc, sockets and windows sp2

2005-04-08 Thread kraken+spam
On Apr 4 18:05, Vincent Dedun wrote: 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. What you see is intermixed debug output

Re: ipc, sockets and windows sp2

2005-04-06 Thread Corinna Vinschen
On Apr 4 18:05, Vincent Dedun wrote: > 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. What you see is intermixed d

Re: ipc, sockets and windows sp2

2005-04-04 Thread 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.

RE: ipc, sockets and windows sp2

2005-04-04 Thread Dave Korn
Original Message >From: Corinna Vinschen >Sent: 04 April 2005 15:26 > On Apr 4 14:45, Dave Korn wrote: >> Incidentally, what's the difference between the cygwin0.dll and the >> new-cygwin1.dll, anyone? Is the -0.dll the > > The cygwin0.dll is tweaked to run in the testsuite, while ano

Re: ipc, sockets and windows sp2

2005-04-04 Thread Corinna Vinschen
On Apr 4 16:25, Corinna Vinschen wrote: > On Apr 4 14:45, Dave Korn wrote: > > Incidentally, what's the difference between the cygwin0.dll and the > > new-cygwin1.dll, anyone? Is the -0.dll the > > The cygwin0.dll is tweaked to run in the testsuite, while another version > of Cygwin is still

Re: ipc, sockets and windows sp2

2005-04-04 Thread Corinna Vinschen
On Apr 4 14:45, Dave Korn wrote: > Incidentally, what's the difference between the cygwin0.dll and the > new-cygwin1.dll, anyone? Is the -0.dll the The cygwin0.dll is tweaked to run in the testsuite, while another version of Cygwin is still running. Corinna -- Corinna Vinschen

Re: ipc, sockets and windows sp2

2005-04-04 Thread Corinna Vinschen
On Apr 4 15:13, Vincent Dedun wrote: > i have no idea how to do this, i'm not a good system programmer. gdb? > further more, i have a slow computer, and recompiling cygwin is long. > I even don't know how to active debugging (dprintf) on cygwin dll. The debug output in cygserver is activated by

Re: ipc, sockets and windows sp2

2005-04-04 Thread Brian Dessent
Dave Korn wrote: > Incidentally, what's the difference between the cygwin0.dll and the > new-cygwin1.dll, anyone? Is the -0.dll the > specially-tweaked-for-running-make-check-without-clashing-with-the-existing- > one one? I'm fairly sure it's the new-* dll that gets installed by "make > instal

RE: ipc, sockets and windows sp2

2005-04-04 Thread Dave Korn
Original Message >From: Vincent Dedun >Sent: 04 April 2005 14:14 > i tried to test this, but when i modify cygwin sources and compil, my > cygwin0.dll is not updated, i don't want to recompil everything each > time, it take too longs. cd /i686-pc-cygwin/winsup/cygwin make all will just

Re: ipc, sockets and windows sp2

2005-04-04 Thread Vincent Dedun
Corinna Vinschen wrote : On Apr 4 08:52, Vincent Dedun wrote: However, semaphores still doesn't work properly. There is no more problem with semop not waiting, but with quick semaphores locking unlocking. I attach a new testcase, which is the same as previous one, except each child task will lock

Re: ipc, sockets and windows sp2

2005-04-04 Thread Corinna Vinschen
On Apr 4 08:52, Vincent Dedun wrote: > However, semaphores still doesn't work properly. > There is no more problem with semop not waiting, but with quick > semaphores locking unlocking. > > I attach a new testcase, which is the same as previous one, except each > child task will lock the semaph

Re: ipc, sockets and windows sp2

2005-04-03 Thread Vincent Dedun
Corinna Vinschen wrote : Thanks again for the testcase. It helped to track down the problem which was a result of my previous check in. It should be solved in CVS now. Since you're building from CVS anyway, I don't create another snapshot for now. We're that close to 1.5.14 anyway... Thanks a

Re: ipc, sockets and windows sp2

2005-04-01 Thread Corinna Vinschen
On Apr 1 16:36, Vincent Dedun wrote: > I recompiled from the cygwin cvs, and it solved my problem, my master > now runs well. > > However, there is still a problem, sorry ;) Thanks again for the testcase. It helped to track down the problem which was a result of my previous check in. It shoul

Re: ipc, sockets and windows sp2

2005-04-01 Thread Vincent Dedun
Corinna Vinschen wrote : So I hope you wouldn't mind I attached a short testing program you can easily compil with gcc to reproduce the bug. Cool, that's exactly what I was asking for. I was immediately able to reproduce the problem and it turned out, that on fork() the socket duplication fr

Re: ipc, sockets and windows sp2

2005-04-01 Thread Corinna Vinschen
On Apr 1 13:05, Vincent Dedun wrote: > So I hope you wouldn't mind I attached a short testing program you can > easily compil with gcc to reproduce the bug. Cool, that's exactly what I was asking for. I was immediately able to reproduce the problem and it turned out, that on fork() the socket d

Re: ipc, sockets and windows sp2

2005-04-01 Thread Vincent Dedun
Corinna Vinschen wrote : There seems to be odd problems with windows sp2 (and some sp1 with undetermined updates). Never heard of Windows sp2. NT4 SP2? 2000 SP2? XP SP2? I'm sorry I sometimes forget there are several windows versions. I'm using windows xp sp2 with all lastest microsoft

Re: ipc, sockets and windows sp2

2005-04-01 Thread Corinna Vinschen
On Apr 1 10:11, Vincent Dedun wrote: > There seems to be odd problems with windows sp2 (and some sp1 with > undetermined updates). Never heard of Windows sp2. NT4 SP2? 2000 SP2? XP SP2? > I work on windows version of drqueue, which is an opensource distributed > rendering management softwar

ipc, sockets and windows sp2

2005-04-01 Thread Vincent Dedun
There seems to be odd problems with windows sp2 (and some sp1 with undetermined updates). I work on windows version of drqueue, which is an opensource distributed rendering management software (for use with maya rendering for exemple), designed for unix, so it uses IPC ans sockets. The port wo