[EMAIL PROTECTED] wrote:
>
> wsanchez02/05/01 15:50:45
>
> Modified:dso/unix dso.c
> Log:
> Or'ing NSLINKMODULE_OPTION_NONE is verbose.
But still valid and makes the setting explicit. Plus, I think the below
is wrong (handle vs os_handle)
> Darwin comment is true on all platform
On Wed, May 01, 2002 at 11:01:47AM -0700, Aaron Bannert wrote:
> Sorry for the late reply. Do we have a HAVE_DEV_ZERO-like define
> somewhere, and if so would this mean that an OS that had /dev/zero but
> didn't support mmap(/dev/zero) would not have that defined anymore? Other
> than that I think
On Wed, May 01, 2002 at 10:56:10AM -0700, Aaron Bannert wrote:
> Since this doesn't really disable the atomics, please rename
> it. Something like --disable-optimized-atomics, or how about
> --enable-nonportable-atomics.
No one came up with a patch to do it after lots of discussion about
it. If y
On Sun, Apr 28, 2002 at 07:49:34AM -, Justin Erenkrantz wrote:
> jerenkrantz02/04/28 00:49:34
>
> Modified:.configure.in CHANGES
> Log:
> Not all platforms can mmap /dev/zero, so we need to do an explicit check
> for that. If that were to fail, then make it appear as /
On Wed, May 01, 2002 at 01:46:56AM +0100, Pier Fumagalli wrote:
> "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
> > + *) Remove Linux atomic support since it does not have a usable
> > + userspace atomic interface. [Justin Erenkrantz]
>
> I believe that is at least fair that if we suppor
On Tue, Apr 30, 2002 at 11:49:41PM -, Justin Erenkrantz wrote:
> jerenkrantz02/04/30 16:49:41
>
> Modified:.configure.in
> Log:
> Add --disable-atomics flag which will prevent APR from using its *own*
> optimized code. On those OSes that properly support atomics from u
I wasn't actually using it in the MPM. I have a module that needs this
support, and it wasn't working. Having this function separate from APR
is wrong IMNSHO. This means that anybody who wants to change
permissions on a lock must implement this feature themselves. That
isn't going to work long-
"Ryan Bloom" <[EMAIL PROTECTED]> writes:
> The problem is that in Apache we create the semaphore as root, and then
> try to use it as a child process running as nobody. Of course, the
> child process doesn't have the rights to access that semaphore.
which MPM are you using? see the call to unix
The problem is that in Apache we create the semaphore as root, and then
try to use it as a child process running as nobody. Of course, the
child process doesn't have the rights to access that semaphore. The
attached patch solves the problem for HP/UX, but how is this working
anywhere?
As a side
INOUE Seiichiro <[EMAIL PROTECTED]> writes:
> apr_time_exp_get() (a.k.a. apr_implode_time()) has a weird difference between
> Unix and Win32.
> Only on Win32, it has
> days -= xt->tm_gmtoff;
>
> Is this a bug?
> Or, a platform dependent code?
good question!
--
Jeff Trawick | [EMAIL PROTEC
Joe Orton <[EMAIL PROTECTED]> writes:
> On Tue, Apr 30, 2002 at 11:43:29PM -, Justin Erenkrantz wrote:
> > Modified:include apr_atomic.h
> > Log:
> > Remove Linux atomic support as this is most definitely not meant for
> > userspace applications. We will have to come up with proc
On Tue, Apr 30, 2002 at 11:43:29PM -, Justin Erenkrantz wrote:
> Modified:include apr_atomic.h
> Log:
> Remove Linux atomic support as this is most definitely not meant for
> userspace applications. We will have to come up with processor-specific
> implementations, but we can no
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> + *) Remove Linux atomic support since it does not have a usable
> + userspace atomic interface. [Justin Erenkrantz]
I believe that is at least fair that if we support atomic in APR and those
are not available in Linux, we do the same for AF_
13 matches
Mail list logo
