apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Havard" <bri...@kheldar.apana.org.au>
Subject Re: cvs commit: apr/include apr_thread_proc.h
Date Sat, 24 Feb 2001 02:17:29 GMT
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 && !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 |

View raw message