Svante Signell, le sam. 08 déc. 2018 01:14:34 +0100, a ecrit:
> On Mon, 2018-12-03 at 12:17 +0100, Samuel Thibault wrote:
> > Samuel Thibault, le lun. 03 déc. 2018 12:14:42 +0100, a ecrit:
> > > to which you'd pass MACH_PORT_NULL for now. And in the server, in the
> > > GETLK case, set the l_pid f
On Mon, 2018-12-03 at 12:17 +0100, Samuel Thibault wrote:
> Samuel Thibault, le lun. 03 déc. 2018 12:14:42 +0100, a ecrit:
> > to which you'd pass MACH_PORT_NULL for now. And in the server, in the
> > GETLK case, set the l_pid field to -1 for now.
>
> More precisely: in the server, for now set th
Samuel Thibault, le lun. 03 déc. 2018 12:14:42 +0100, a ecrit:
> to which you'd pass MACH_PORT_NULL for now. And in the server, in the
> GETLK case, set the l_pid field to -1 for now.
More precisely: in the server, for now set the field to -1 if the port
is null, and return EOPNOTSUPP if the port
Hello,
Svante Signell, le dim. 02 déc. 2018 17:06:17 +0100, a ecrit:
> On Mon, 2016-02-08 at 23:33 +0100, Samuel Thibault wrote:
> > Svante Signell, on Mon 08 Feb 2016 12:51:42 +0100, wrote:
> > > 1) Locks are inherited by fork, they should not. Test program: libfshelp-
> > > tests/fork.c
> >
> >
On Mon, 2016-02-08 at 23:33 +0100, Samuel Thibault wrote:
> Svante Signell, on Mon 08 Feb 2016 12:51:42 +0100, wrote:
> > 1) Locks are inherited by fork, they should not. Test program: libfshelp-
> > tests/fork.c
>
> As I mentioned previously, this should be fine for now.
>
> > 2) The pid of a co
Svante Signell, on Thu 25 Feb 2016 10:16:59 +0100, wrote:
> On Mon, 2016-02-08 at 23:33 +0100, Samuel Thibault wrote:
> > Svante Signell, on Mon 08 Feb 2016 12:51:42 +0100, wrote:
> > > 1) Locks are inherited by fork, they should not. Test program: libfshelp-
> > > tests/fork.c
> >
> > As I mentio
On Mon, 2016-02-08 at 23:33 +0100, Samuel Thibault wrote:
> Svante Signell, on Mon 08 Feb 2016 12:51:42 +0100, wrote:
> > 1) Locks are inherited by fork, they should not. Test program: libfshelp-
> > tests/fork.c
>
> As I mentioned previously, this should be fine for now.
>
> > 2) The pid of a co
Svante Signell, on Mon 08 Feb 2016 12:51:42 +0100, wrote:
> 1) Locks are inherited by fork, they should not. Test program: libfshelp-
> tests/fork.c
As I mentioned previously, this should be fine for now.
> 2) The pid of a conflicting process locking a file is not returned.
Similarly, we can mak
I can only repeat myself:
Svante Signell, on Mon 08 Feb 2016 12:51:42 +0100, wrote:
> +++ hurd-0.7.git20160114/libfshelp/rlock.h
> +
> +//#include
Why not? That'd avoid copy/pasting the pthread_cond_init
> +extern int pthread_cond_init (pthread_cond_t *__restrict cond,
> +
Missing features:
1) Locks are inherited by fork, they should not. Test program: libfshelp-
tests/fork.c
2) The pid of a conflicting process locking a file is not returned.
Both problems will be solved by implementation of the
proc_user_identify/proc_server_identify RPCs with corresponding adjust
Svante Signell, le Thu 08 Jan 2015 12:28:24 +0100, a écrit :
> hurd: add new RPC: file_record_lock
It seems good.
> hurd/ChangeLog
> 2014-08-21 Svante Signell
>
> * fs.defs: Added description.
> * hurd_types.defs: Make struct flock_t seven integers long since
> l_start and
hurd: add new RPC: file_record_lock
hurd/ChangeLog
2014-08-21 Svante Signell
* fs.defs: Added description.
* hurd_types.defs: Make struct flock_t seven integers long since
l_start and l_len are 64bit.
* hurd_types.h: typedef flock_t as flock64.
2001-04-10 Neal H Walfield
* fs.defs: N
12 matches
Mail list logo
