You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by bj...@apache.org on 2001/02/23 10:09:47 UTC
cvs commit: apr/include apr_thread_proc.h
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.
Revision Changes Path
1.56 +1 -1 apr/include/apr_thread_proc.h
Index: apr_thread_proc.h
===================================================================
RCS file: /home/cvs/apr/include/apr_thread_proc.h,v
retrieving revision 1.55
retrieving revision 1.56
diff -u -r1.55 -r1.56
--- apr_thread_proc.h 2001/02/21 13:21:46 1.55
+++ apr_thread_proc.h 2001/02/23 09:09:46 1.56
@@ -584,7 +584,7 @@
APR_DECLARE(void) apr_pool_note_subprocess(apr_pool_t *a, apr_proc_t *pid,
enum kill_conditions how);
-#if APR_HAS_THREADS
+#if APR_HAS_THREADS && !defined(OS2)
/**
* Setup the process for a single thread to be used for all signal handling.
* @warn This must be called before any threads are created
Re: cvs commit: apr/include apr_thread_proc.h
Posted by Brian Havard <br...@kheldar.apana.org.au>.
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 list.
>>
>>
>> -#if APR_HAS_THREADS
>> +#if APR_HAS_THREADS && !defined(OS2)
>> /**
>> * Setup the process for a single thread to be used for all signal handling.
>> * @warn This must be called before any threads are created
>>
>
>
>Just a nit ... I consider this change wrong in spirit - I'd really, really like to
>see a feature macro spelling out what this exception is and why.
>
>It's going to become impossible to use any Unix mpms on OS2 if the code is blocked
>in this way. Maybe the issue is partly rbb's original contribution on signal handling
>that opened up this chicken and egg, but unless this is -broken- on OS2 (couldn't
>work for any app) - then even if your OS2 mpm isn't using it - I'd hate to see us
>create APR crippleware.
It's not meant to be a permanent solution. I had to do this to fix a
compile break as these functions don't build under OS/2 the way they are.
The correct solution is of course to write an OS/2 implementation but to do
so I need to figure out just what they do & determine if it's actually
possible on OS/2.
I guess I could have just added stubs that return APR_ENOTIMPL instead.
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: cvs commit: apr/include apr_thread_proc.h
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
> 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 && !defined(OS2)
> /**
> * Setup the process for a single thread to be used for all signal handling.
> * @warn This must be called before any threads are created
>
Just a nit ... I consider this change wrong in spirit - I'd really, really like to
see a feature macro spelling out what this exception is and why.
It's going to become impossible to use any Unix mpms on OS2 if the code is blocked
in this way. Maybe the issue is partly rbb's original contribution on signal handling
that opened up this chicken and egg, but unless this is -broken- on OS2 (couldn't
work for any app) - then even if your OS2 mpm isn't using it - I'd hate to see us
create APR crippleware.
Bill