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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
23 matches
Mail list logo