Daniel Eischen wrote:
> > No, libc_r doesn't properly handle flock. Usually, all syscalls
> > that take file descriptors as arguments honor the non-blocking
> > mode of the file if set. I guess flock(2) doesn't and has its
> > own option to the operation argument (LOCK_NB).
> >
> > I hacked libc_
Brian Smith wrote:
> On Mon, 18 Nov 2002 22:05:34 -0800, Terry Lambert wrote:
> >Use mmap of a backing-store file, and then use file locking to
> >do record locking in the shared memory segment.
>
> Ok, I did this, and it actually works considerably better than
> the SysV shared memory. However f
On Sat, 30 Nov 2002, Daniel Eischen wrote:
> On Sat, 30 Nov 2002, Brian Smith wrote:
>
> > On Mon, 18 Nov 2002 22:05:34 -0800, Terry Lambert wrote:
> >
> > >Use mmap of a backing-store file, and then use file locking to
> > >do record locking in the shared memory segment.
> >
> > Ok, I did this,
On Sat, 30 Nov 2002, Brian Smith wrote:
> On Mon, 18 Nov 2002 22:05:34 -0800, Terry Lambert wrote:
>
> >Use mmap of a backing-store file, and then use file locking to
> >do record locking in the shared memory segment.
>
> Ok, I did this, and it actually works considerably better than
> the SysV
On Mon, 18 Nov 2002 22:05:34 -0800, Terry Lambert wrote:
>Use mmap of a backing-store file, and then use file locking to
>do record locking in the shared memory segment.
Ok, I did this, and it actually works considerably better than
the SysV shared memory. However flock() has the same problem
as
Brian Smith wrote:
> >Sure SysV semaphores are thread-safe. When a thread blocks on
> >one, the entire process blocks (no threads run). You won't
> >get any safer than that ;-)
>
> Yikes that isn't good. Is that only in STABLE? or does CURRENT
> do that as well? I guess I'll have to protect t
< said:
> Is this the recommended method of preventing these problems?
The recommended method of preventing these problems generally is to
use POSIX semaphores (or other POSIX synchronization mechanisms
appropriate to threaded programs. However, the code to implement
process-shared POSIX semapho
On Mon, 18 Nov 2002 21:33:38 -0500 (EST), Daniel Eischen wrote:
>[ I assume you mean semop, semctl, not sema_* or sem_* ]
Yes ... semop() specifically is causing the problems...
>Sure SysV semaphores are thread-safe. When a thread blocks on
>one, the entire process blocks (no threads run). You
On Mon, 18 Nov 2002, Brian Smith wrote:
> I've been porting an application from Linux to FreeBSD using STABLE, and it appears
>from looking at the
> semaphore code that the SysV semaphores are not thread safe on STABLE. I don't have
>CURRENT source
> code to look at currently. Does anyone k
I've been porting an application from Linux to FreeBSD using STABLE, and it appears
from looking at the
semaphore code that the SysV semaphores are not thread safe on STABLE. I don't have
CURRENT source
code to look at currently. Does anyone know if they are thread-safe in CURRENT?
Thanks!
10 matches
Mail list logo