[EMAIL PROTECTED] writes:
> jim 02/04/04 10:33:57
>
> Modified: . CHANGES configure.in
> include apr.h.in apr_global_mutex.h apr_lock.h
> apr_proc_mutex.h
> include/arch/unix locks.h proc_mutex.h
> locks/unix crossproc.c locks.c proc_mutex.c
> Log:
> Support for Posix semaphores for locking has been added. This uses
> named semaphores (sem_open). Because there are a few different
> implementations around, this uses the lowest common denominator in
> creating the semaphore name. As far as its location in DEFAULT
> priority, it's placed between pthread and sysvsem. Tested on
> Darwin (in which it's the new default) and Solaris.
"sem_open("/ApR.whatever", O_CREAT, 0644,1)" returns ENOSYS on Linux
(2.2.12 kernel). I'll try to add an autoconf check for that.
Beyond the issue mentioned above, why is a new lock mechanism
suddenly so high in the priority list? Aren't we throwing away a lot
of past experience (1.3 and 2.0)?
--
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...
