Svante Signell, le Sat 28 Feb 2015 15:32:47 +0100, a écrit :
> * how come?
> - code calling fcntl() works.
> - code calling the (RPC) file_record_lock() does not!
Which code? Without showing what you are doing, it's difficult for us to
understand what you mean.
> * the code below iterates over th
Hi,
One remaining problem with the file record lock patches are that the
child after fork inherits the parent's locks. (YES; tdbtorture works
when this code is OK, tried ot differently for now). I've tried
different versions of the lock code and the code below works for some
client code, but not f
Richard Braun, le Sat 28 Feb 2015 13:05:07 +0100, a écrit :
> I'd say that glibc (in mmap) should add a reference to the file. On
> munmap or process termination, all references are dropped.
Looks like a very hard way to fix a corner issue :)
It'd mean tracking what was mapped, whether some parts
On Sat, Feb 28, 2015 at 01:05:07PM +0100, Richard Braun wrote:
> I'd say that glibc (in mmap) should add a reference to the file. On
> munmap or process termination, all references are dropped.
Forget this, it obviously can't work since mmap and munmap can be
asymmetric.
--
Richard Braun
On Sat, Feb 28, 2015 at 12:22:47PM +0100, Samuel Thibault wrote:
> For instance the X server crashes on fvwm startup, or mupdf crashes,
> when /run is served by a tmpfs.
>
> What happens is that they create an shm (shmget, thus a file in
> /run/shm/, backed by tmpfs), then map it (shmat, i.e. open
Hello,
For instance the X server crashes on fvwm startup, or mupdf crashes,
when /run is served by a tmpfs.
What happens is that they create an shm (shmget, thus a file in
/run/shm/, backed by tmpfs), then map it (shmat, i.e. open/mmap/close of
the file), then remove access to it (shmctl(IPC_RMID
