Re: cvs commit: apr/threadproc/unix signals.c
> --- apr_threads.m4 2001/02/20 01:53:47 1.2 > +++ apr_threads.m4 2001/02/21 01:15:47 1.3 > @@ -156,3 +156,27 @@ >fi >])dnl > > +AC_DEFUN(APACHE_CHECK_SIGWAIT_ONE_ARG,[ I think this should be APR_CHECK_SIGWAIT_ONE_ARG. The APACHE_ prefix is for macros in httpd. Roy
Re: cvs commit: apr/threadproc/unix signals.c
[EMAIL PROTECTED] writes: > rbb 01/02/20 17:15:49 > > Modified:buildapr_threads.m4 >include apr_thread_proc.h >threadproc/unix signals.c > Log: > Add some functions to APR's thread/processes support to allow a single > thread to handle all signal processing. this was a doozy (sp?) of a commit new configure warnings/errors: buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: libtool version 1.3.5 (ok) rebuilding aclocal.m4 rebuilding configure ./aclocal.m4:214: /bin/m4: Warning: Excess arguments to built-in `define' ignored configure.in:70: AC_TRY_COMPILE was called before AC_AIX configure.in:71: AC_TRY_COMPILE was called before AC_ISC_POSIX configure.in:72: AC_TRY_COMPILE was called before AC_MINIX rebuilding include/ap_config_auto.h.in ./aclocal.m4:214: /bin/m4: Warning: Excess arguments to built-in `define' ignored configure.in:70: AC_TRY_COMPILE was called before AC_AIX configure.in:71: AC_TRY_COMPILE was called before AC_ISC_POSIX configure.in:72: AC_TRY_COMPILE was called before AC_MINIX rebuilding srclib/apr/configure new link-edit errors: apr_sigwait() unresolved -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: apr/threadproc/unix signals.c
Jeff Trawick <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] writes: > > > rbb 01/02/20 17:15:49 > > > > Modified:buildapr_threads.m4 > >include apr_thread_proc.h > >threadproc/unix signals.c > > Log: > > Add some functions to APR's thread/processes support to allow a single > > thread to handle all signal processing. > > this was a doozy (sp?) of a commit > > new configure warnings/errors: > > buildconf: checking installation... > buildconf: autoconf version 2.13 (ok) > buildconf: libtool version 1.3.5 (ok) > rebuilding aclocal.m4 > rebuilding configure > ./aclocal.m4:214: /bin/m4: Warning: Excess arguments to built-in `define' > ignored > configure.in:70: AC_TRY_COMPILE was called before AC_AIX > configure.in:71: AC_TRY_COMPILE was called before AC_ISC_POSIX > configure.in:72: AC_TRY_COMPILE was called before AC_MINIX okay, maybe I can't pin this one on you :) I don't know exactly when this started. Unfortunately my build regression doesn't track changes to the stdout/stderr of buildconf (about to fix), so easy clues about the offending commit are not present. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: apr/threadproc/unix signals.c
On Tue, 20 Feb 2001, Roy T. Fielding wrote: > > --- apr_threads.m42001/02/20 01:53:47 1.2 > > +++ apr_threads.m42001/02/21 01:15:47 1.3 > > @@ -156,3 +156,27 @@ > >fi > >])dnl > > > > +AC_DEFUN(APACHE_CHECK_SIGWAIT_ONE_ARG,[ > > I think this should be APR_CHECK_SIGWAIT_ONE_ARG. The APACHE_ prefix > is for macros in httpd. Yep, my bad. I'll fix it immediately. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
RE: cvs commit: apr/threadproc/unix signals.c
> -Original Message- > Modified:.acconfig.h >threadproc/unix signals.c > Log: > Add apr_sigwait to the apr_private.h file. This allows us to remove > a couple of #ifdefs, and standardize some code. This macro comes directly > from the Apache code. But if you put it in apr_private.h, Apache can't get to it... and you removed the Apache version of this macro (ap_sigwait) from ap_config.h in rev. 1.57... where did it go? I'd think we could just expose the apr_sigwait as non-private and let Apache use that. Or have I missed something? --Cliff
RE: cvs commit: apr/threadproc/unix signals.c
On Wed, 21 Feb 2001, Cliff Woolley wrote: > > -Original Message- > > Modified:.acconfig.h > >threadproc/unix signals.c > > Log: > > Add apr_sigwait to the apr_private.h file. This allows us to remove > > a couple of #ifdefs, and standardize some code. This macro comes directly > > from the Apache code. > > But if you put it in apr_private.h, Apache can't get to it... and you removed > the Apache version of this macro (ap_sigwait) from ap_config.h in rev. 1.57... > where did it go? I'd think we could just expose the apr_sigwait as > non-private > and let Apache use that. Or have I missed something? Apache should not use sigwait anymore. I am fixing perchild so that it uses the APR signal thread now. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: cvs commit: apr/threadproc/unix signals.c
[EMAIL PROTECTED] writes: > These are a bit too unix specific for OS/2 (pthread/sigwait). ... > Index: signals.c > === > RCS file: /home/cvs/apr/threadproc/unix/signals.c,v > retrieving revision 1.22 > retrieving revision 1.23 > diff -u -r1.22 -r1.23 > --- signals.c 2001/02/21 20:49:28 1.22 > +++ signals.c 2001/02/23 02:06:14 1.23 > @@ -267,7 +267,7 @@ > >#endif /* SYS_SIGLIST_DECLARED */ > > -#if APR_HAS_THREADS > +#if APR_HAS_THREADS && !defined(OS2) Why don't you need the same construct in apr_thread_proc.h so that exports.c doesn't try to reference apr_create_signal_thread/apr_setup_signal_thread? (Oh, and where is that Perl guy? We got the verb before the object with these functions.) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: apr/threadproc/unix signals.c
On 22 Feb 2001 21:57:46 -0500, Jeff Trawick wrote: >[EMAIL PROTECTED] writes: > >> These are a bit too unix specific for OS/2 (pthread/sigwait). >... >> Index: signals.c >> === >> RCS file: /home/cvs/apr/threadproc/unix/signals.c,v >> retrieving revision 1.22 >> retrieving revision 1.23 >> diff -u -r1.22 -r1.23 >> --- signals.c 2001/02/21 20:49:28 1.22 >> +++ signals.c 2001/02/23 02:06:14 1.23 >> @@ -267,7 +267,7 @@ >> >>#endif /* SYS_SIGLIST_DECLARED */ >> >> -#if APR_HAS_THREADS >> +#if APR_HAS_THREADS && !defined(OS2) > >Why don't you need the same construct in apr_thread_proc.h so that >exports.c doesn't try to reference >apr_create_signal_thread/apr_setup_signal_thread? Err, because I haven't done a full rebuild so missed it, fixing now. Thanks. -- __ | Brian Havard | "He is not the messiah! | | [EMAIL PROTECTED] | He's a very naughty boy!" - Life of Brian | --
Re: cvs commit: apr/threadproc/unix signals.c
[EMAIL PROTECTED] writes: > trawick 01/11/12 11:47:31 > > Modified:.CHANGES >threadproc/unix signals.c > Log: > Fix apr_setup_signal_thread() so that threads don't block > synchronous signals (e.g., SIGSEGV). It is a programming error > to do so, and some platforms (e.g., Solaris, AIX) don't call any > registered signal handler when such signals are blocked. > > Thanks are due to Dick Dunbar <[EMAIL PROTECTED]>, who pointed > this out to me in the context of debugging a threaded module for > Apache 1.3. a couple of points... 1) on my Solaris 8 account, I now get coredumps in the right place using the worker MPM and a module of mine which generates invalid storage references on demand; before compiling with only this change, I didn't get a coredump from the same test 2) it is unclear to me at the moment whether or not we should keep the synchronous signals out of the set we pass to sigwait()... just in case this is needed, I extracted the knowledge of how to remove synchronous signals into a separate function, ready to be called by apr_signal_thread() if the need ever arises -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
