Default is no-op on every platform except for NetWare which is NO. By default we want to run
child in the current address space, the same as the parent process instead of using separate ones.
Performance and complexity are two main reasons.
This is something specific to the NetWare OS that will
[EMAIL PROTECTED] wrote:
clar2004/06/14 12:36:59
Modified:include apr_thread_proc.h
Log:
Fixed typo in API description
Revision ChangesPath
1.108 +1 -1 apr/include/apr_thread_proc.h
Index: apr_thread_proc.h
=
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
> >clar2004/06/11 13:13:19
> >
> > Added NetWare specific option in apr_cmdtype_e to start program in a
separate address space for cmdtype field in apr_procattr_t struct
> >
> > --- apr_thread_proc.h 10 Jun 2004 10:57:24 - 1.105
> > +++ apr_thread_proc.h 11 Jun 2004 20:13:19 -00
>clar2004/06/11 13:13:19
>
> Added NetWare specific option in apr_cmdtype_e to start program in a
> separate address space for cmdtype field in apr_procattr_t struct
>
> --- apr_thread_proc.h 10 Jun 2004 10:57:24 - 1.105
> +++ apr_thread_proc.h 11 Jun 2004 20:13:19 -
(should have sent this to the list originally)
--- Begin Message ---
Brad Nicholes wrote:
We considered that but decided that adding a NetWare only enum was
less intrusive than adding a NetWare only API to APR. I'm fine with it
either way, this just seemed a little cleaner. All of the other enu
We considered that but decided that adding a NetWare only enum was
less intrusive than adding a NetWare only API to APR. I'm fine with it
either way, this just seemed a little cleaner. All of the other enums
are a no-ops for us since those concepts don't exist on NetWare. We
figured that it wo
[EMAIL PROTECTED] wrote:
clar2004/06/11 13:13:19
Modified:include apr_thread_proc.h
Log:
Added NetWare specific option in apr_cmdtype_e to start program in a separate address space for cmdtype field in apr_procattr_t struct
Revision ChangesPath
1.106 +7 -4 ap
On 28 Jul 2001 [EMAIL PROTECTED] wrote:
> bjh 01/07/27 20:26:59
>
> Modified:include apr_thread_proc.h
> Log:
> Reorder test so make_exports.awk recognises that it needs to go in exports.c
>
> Revision ChangesPath
> 1.68 +1 -1 apr/include/apr_thread_proc.h
>
>
It gets you (and I) the apr_thread_pool_get declaration that _used_ to hide
within this very same block, which was bad mojo.
Bill
- Original Message -
From: "Brian Havard" <[EMAIL PROTECTED]>
To:
Sent: Friday, July 27, 2001 5:41 AM
Subject: Re: cvs commit: apr/include a
From: "Brian Havard" <[EMAIL PROTECTED]>
Sent: Friday, July 27, 2001 11:30 AM
> On Fri, 27 Jul 2001 11:09:55 -0500, William A. Rowe, Jr. wrote:
>
> >It gets you (and I) the apr_thread_pool_get declaration that _used_ to hide
> >within this very same block, which was bad mojo.
>
> Ah, ok, didn't
On Fri, 27 Jul 2001 11:09:55 -0500, William A. Rowe, Jr. wrote:
>It gets you (and I) the apr_thread_pool_get declaration that _used_ to hide
>within this very same block, which was bad mojo.
Ah, ok, didn't spot that. That's another that will need its export fixed
though nothing appears to use it
Ouch! This breaks OS/2 as the !defined(OS2) condition doesn't make it into
exports.c. Changing it to
#if APR_HAVE_SIGWAIT && !defined(OS2)
fixes it but I'd like to know what the below patch actually achieves.
On 27 Jul 2001 05:37:13 -, [EMAIL PROTECTED] wrote:
>wrowe 01/07/26 22:37:
Sorry about that. Two different patches caused this. I made the change
on BeOS, and it worked, so I committed it. Then I brought it back to my
machine, and it failed. At that point, I added the APR_HAVE_SIGWAIT
macro, and obviosly re-broke the code. Thanks for the fix.
Ryan
On 25 Feb 2001 [
On Fri, 23 Feb 2001 10:50:45 -0600, William A. Rowe, Jr. wrote:
>> bjh 01/02/23 01:09:47
>>
>> Modified:include apr_thread_proc.h
>> Log:
>> apr_setup_signal_thread() & apr_create_signal_thread() aren't implemented
>> on
>> OS/2 (or needed AFAIK) so keep them out of exports
> bjh 01/02/23 01:09:47
>
> Modified:include apr_thread_proc.h
> Log:
> apr_setup_signal_thread() & apr_create_signal_thread() aren't implemented on
> OS/2 (or needed AFAIK) so keep them out of exports list.
>
>
> -#if APR_HAS_THREADS
> +#if APR_HAS_THREADS && !defi
19 matches
Mail list logo
