apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mathihalli, Madhusudan" <mad...@hp.com>
Subject RE: [PATCH] New api's apr_block_signal and apr_unblock_signal
Date Tue, 20 Apr 2004 22:26:29 GMT
Since I didn't get any negative feedback, can I take that it's okay to commit the change ?

-Madhu

>-----Original Message-----
>From: Mathihalli, Madhusudan 
>Sent: Monday, April 19, 2004 11:09 PM
>To: dev@apr.apache.org
>Subject: RE: [PATCH] New api's apr_block_signal and apr_unblock_signal
>
>
>>>       Since a lot of the async signals are blocked by 
>default, I thought
>>> it'll be good to provide a apr_(un)block_signal() api for 
>those who want
>>> to block/unblock only select signals. Here's a patch to do that.
>>
>>Is this portable?  (Admitting my ignorance of the Win32 API here.)
>
>I also have to admit my ignorance of beos and os2. Both of 
>them include the code in unix/signals.c. There are no new 
>system calls introduced apart from what is already existing in 
>unix/signals.c. The new library calls are sigaddset() and 
>sigemptymask(). These functions should be available on all 
>system that have sigdelset() / sigfillmask(). Hence, I believe 
>the code itself is as portable as the rest of the code in 
>unix/signals.c.
>
>I did not see any specific handling of the signals for Win32 
>and Netware. If somebody could evaluate the need for the 
>block/unblock feature on those systems, that'll be great.
>
>>PS: the names should be apr_signal_block and 
>apr_signal_unblock instead.
>
>Sure ! 
>
>-Madhu
>
>

Mime
View raw message