On Thu, May 27, 2004 at 08:19:00AM -, [EMAIL PROTECTED] wrote:
> jfclere 2004/05/27 01:19:00
>
> Added: xml/expat/lib map_osd_ebcdic_df04_1.h
> Log:
> Table for the OSD_EBCDIC_DF04_1 encoding.
> See http://www.iana.org/assignments/charset-reg/OSD-EBCDIC-DF04-1 for more
> in
[EMAIL PROTECTED] wrote:
clar2004/06/14 10:26:20
Modified:include apr_thread_proc.h
include/arch/netware apr_arch_threadproc.h
threadproc/beos proc.c
threadproc/netware proc.c
threadproc/os2 proc.c
threadproc/
Joe Orton wrote:
On Mon, Jun 14, 2004 at 08:22:41AM -0400, Jeff Trawick wrote:
Joe Orton wrote:
So, I'm proposing that _POSIXSEM or _PROC_PTHREAD should never be made
the default locking mechanism. Nothing to stop those who understand the
trade-off making an informed choice, of course.
generally
Brad Nicholes wrote:
Is there a reason why the apr_procattr APIs were implemented as
apr_procattr_xxx_set (apr_procattr_t*, value)
rather than
apr_procattr_set (apr_procattr_t*, APR_xxx_ATTR, value, ...)
that's before my time, but I'd guess:
preserves typechecking on values
On Mon, Jun 14, 2004 at 09:19:33AM -0600, Brad Nicholes wrote:
>Is there a reason why the apr_procattr APIs were implemented as
>
> apr_procattr_xxx_set (apr_procattr_t*, value)
>
> rather than
>
> apr_procattr_set (apr_procattr_t*, APR_xxx_ATTR, value, ...)
Because the different accessors
On Mon, 14 Jun 2004, Brad Nicholes wrote:
>Is there a reason why the apr_procattr APIs were implemented as
>
> apr_procattr_xxx_set (apr_procattr_t*, value)
>
> rather than
>
> apr_procattr_set (apr_procattr_t*, APR_xxx_ATTR, value, ...)
>
> It seems like the second approach would make it ea
Is there a reason why the apr_procattr APIs were implemented as
apr_procattr_xxx_set (apr_procattr_t*, value)
rather than
apr_procattr_set (apr_procattr_t*, APR_xxx_ATTR, value, ...)
It seems like the second approach would make it easier for a platform
to extent the apr_procattr_t structure
On Tue, Jun 08, 2004 at 09:58:10PM -0700, Paul Querna wrote:
> On Mon, 2004-06-07 at 21:21 +0100, Joe Orton wrote:
> > Ah, also pollset_create will need to register a cleanup now there is
> > something to clean up now I notice...
>
> pollset_destroy() ?
It's part of the deal with pools that noth
On Mon, Jun 14, 2004 at 08:22:41AM -0400, Jeff Trawick wrote:
> Joe Orton wrote:
>
> >So, I'm proposing that _POSIXSEM or _PROC_PTHREAD should never be made
> >the default locking mechanism. Nothing to stop those who understand the
> >trade-off making an informed choice, of course.
>
> generally
Title: Dear PayPal user
Dear PayPal User,
We recently reviewed your account, and suspect that your PayPal account may
have been accessed by an unauthorized third party. Protecting the security
of your account and of the PayPal network is our primary concern.
Therefore, as a prevention m
Joe Orton wrote:
So, I'm proposing that _POSIXSEM or _PROC_PTHREAD should never be made
the default locking mechanism. Nothing to stop those who understand the
trade-off making an informed choice, of course.
generally +1, though I'm concerned that Solaris may not have a good default due
to the sy
On Mon, 14 Jun 2004, Justin Erenkrantz wrote:
> --On Saturday, June 12, 2004 9:45 PM -0400 [EMAIL PROTECTED] wrote:
>
> > OK, here is the proc mutex re-org. This is ugly, but it passes all of the
> > tests, using both fork and proc_create. The only problem with this patch,
> > is that it doesn
Having taken the time to review some of the proc mutex code, it seems
both the process-shared pthread mutexes and POSIX semaphores differ from
the other locking types on Unix in two significant ways:
1) for both types, if a process segfaults whilst holding the lock, the
mutex is left in an undefin
--On Saturday, June 12, 2004 9:45 PM -0400 [EMAIL PROTECTED] wrote:
OK, here is the proc mutex re-org. This is ugly, but it passes all of the
tests, using both fork and proc_create. The only problem with this patch,
is that it doesn't do the configure magic to actually setup FORK_DEFAULT
and PROC
14 matches
Mail list logo
