On Jul 22 16:18, Eric Blake wrote:
> Corinna Vinschen cygwin.com> writes:
>
> > Thanks, but no. There's at least this one problem left which I simply
> > don't know how to fix. The situation is thus:
> >
> > fd = open()
> > fork ()
> > --> child
> > flock(fd, LOCK_SH);
> > ex
Corinna Vinschen cygwin.com> writes:
> Thanks, but no. There's at least this one problem left which I simply
> don't know how to fix. The situation is thus:
>
> fd = open()
> fork ()
> --> child
> flock(fd, LOCK_SH);
> exit ();
>
> The problem is that the lock disappears whe
On Jul 22 15:27, Eric Blake wrote:
> Corinna Vinschen cygwin.com> writes:
>
> > > $ ./foo 4& sleep 2; ./foo 0
> > >
> > > Oops - process 14060 got the lock before 12692 and 21704 exited.
> >
> > This looks different with my patch:
> >
>
> Yep, so far, it looks like your patch follows the sema
Corinna Vinschen cygwin.com> writes:
> > $ ./foo 4& sleep 2; ./foo 0
> >
> > Oops - process 14060 got the lock before 12692 and 21704 exited.
>
> This looks different with my patch:
>
Yep, so far, it looks like your patch follows the semantics I expect for every
one of my tests (the lock rem
On Jul 22 14:41, Eric Blake wrote:
> Corinna Vinschen cygwin.com> writes:
>
> >
> > Do you have a working C testcase to demonstrate this?
>
> I still haven't gotten around to trying your patch, but here is the testcase
> I'm using (I guess it's not that simple, after all):
> [...testcase...]
>
Corinna Vinschen cygwin.com> writes:
>
> Do you have a working C testcase to demonstrate this?
I still haven't gotten around to trying your patch, but here is the testcase
I'm using (I guess it's not that simple, after all):
$ cat foo.c
#include
#include
#include
#include
#include
#inclu
On Jul 22 12:08, Corinna Vinschen wrote:
> Does the below patch fix the problem? Does the reasoning sound...
> reasonable?
> [...]
> - node->del_my_locks (after_fork ? 0 : get_unique_id (), get_handle ());
> + node->del_my_locks (after_fork ? 0 : get_unique_id (),
> +
On Jul 21 23:26, Eric Blake wrote:
> I finally figured out why autoconf is still failing its flock-related tests,
> and why perl was reliably failing even though my simple attempts in C were
> always passing. It turns out that if you do:
>
> open
> flock(LOCK_EX)
> if (!fork)
> execlp("sleep"
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 7/21/2009 5:26 PM:
> I'm still trying to figure out why the close-on-exec cleanup appears to be
> spuriously triggering the flock Event to unlock. But my understanding is
> that
> F_FLOCK locks should survive over exec, s
I finally figured out why autoconf is still failing its flock-related tests,
and why perl was reliably failing even though my simple attempts in C were
always passing. It turns out that if you do:
open
flock(LOCK_EX)
if (!fork)
execlp("sleep","sleep","10",NULL);
sleep(10);
then ProcessExplor
10 matches
Mail list logo
