You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by rb...@covalent.net on 2001/02/11 01:52:11 UTC
Re: cvs commit: apr/include apr_signal.h apr.h.in apr_want.h
> *) add apr_signal_get_description() to that platforms (which have signals)
> can portably get descriptions for them.
> *) move signal stuff from apr.h to (new) apr_signal.h
> *) os2/signals.c was collapsed into unix/signals.c
> *) APR initialization will init the signal names (if needed)
If we are going to continue to support signals in APR, I would like to
ressurect the fake signals that I implemented on Windows a long time ago.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apr/include apr_signal.h apr.h.in apr_want.h
Posted by rb...@covalent.net.
On Sat, 10 Feb 2001, Greg Stein wrote:
> On Sat, Feb 10, 2001 at 07:02:25PM -0600, William A. Rowe, Jr. wrote:
> > From: <rb...@covalent.net>
> > Sent: Saturday, February 10, 2001 6:52 PM
> >
> >
> > > > *) add apr_signal_get_description() to that platforms (which have signals)
> > > > can portably get descriptions for them.
> > > > *) move signal stuff from apr.h to (new) apr_signal.h
> > > > *) os2/signals.c was collapsed into unix/signals.c
> > > > *) APR initialization will init the signal names (if needed)
> > >
> > > If we are going to continue to support signals in APR, I would like to
> > > ressurect the fake signals that I implemented on Windows a long time ago.
> >
> > +1, and I'll look at what more we need to do next week.
>
> I don't think we want generic signals. What for?
>
> All that I did was to add a way to portably fetch signal descriptions *IF*
> the platform has them.
>
> There isn't anything about functionality, and I don't know that we need or
> want them in a portable fashion.
I dislike putting stuff that isn't at all portable into APR. When removed
a lot of this stuff from APR a while ago because it was so unportable. If
you look at NSPR, they didn't implement signals, and I believe we should
follow that model.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apr/include apr_signal.h apr.h.in apr_want.h
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Feb 10, 2001 at 07:02:25PM -0600, William A. Rowe, Jr. wrote:
> From: <rb...@covalent.net>
> Sent: Saturday, February 10, 2001 6:52 PM
>
>
> > > *) add apr_signal_get_description() to that platforms (which have signals)
> > > can portably get descriptions for them.
> > > *) move signal stuff from apr.h to (new) apr_signal.h
> > > *) os2/signals.c was collapsed into unix/signals.c
> > > *) APR initialization will init the signal names (if needed)
> >
> > If we are going to continue to support signals in APR, I would like to
> > ressurect the fake signals that I implemented on Windows a long time ago.
>
> +1, and I'll look at what more we need to do next week.
I don't think we want generic signals. What for?
All that I did was to add a way to portably fetch signal descriptions *IF*
the platform has them.
There isn't anything about functionality, and I don't know that we need or
want them in a portable fashion.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apr/include apr_signal.h apr.h.in apr_want.h
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: <rb...@covalent.net>
Sent: Saturday, February 10, 2001 6:52 PM
> > *) add apr_signal_get_description() to that platforms (which have signals)
> > can portably get descriptions for them.
> > *) move signal stuff from apr.h to (new) apr_signal.h
> > *) os2/signals.c was collapsed into unix/signals.c
> > *) APR initialization will init the signal names (if needed)
>
> If we are going to continue to support signals in APR, I would like to
> ressurect the fake signals that I implemented on Windows a long time ago.
+1, and I'll look at what more we need to do next week.