Thanks Jeff and Andy, here is the updated version:
Usage of signals outside the httpd core:
3rd party Apache 2 modules should avoid using code relying on signals.
This is because typical signal use is not thread-saf
On Wed, 01 Dec 2004 19:34:54 -0500, Stas Bekman <[EMAIL PROTECTED]> wrote:
>
>
> Usage of signals outside the httpd core:
>
>
> 3rd party Apache 2 modules should avoid using code relying on signals.
> This is becau
On Thu, 02 Dec 2004 07:41:58 +, Andy Armstrong <[EMAIL PROTECTED]> wrote:
> Stas Bekman wrote:
> [snip]
> > Alternatively one could use a manager thread that implements
> > something like a thread-specific alarm(), where a signal handler
> > running on the interrupted thread does siglongjmp() t
Stas Bekman wrote:
[snip]
Alternatively one could use a manager thread that implements
something like a thread-specific alarm(), where a signal handler
running on the interrupted thread does siglongjmp() to break out of
the interrupted processing, but implementing that sort of service is
not trivia
Jeff Trawick wrote:
[...]
1) what would be the best place to document that in the Apache docs (mpm
include/ap_mpm.h or should each mpm have it documented separately?
how about at
http://httpd.apache.org/docs-2.0/developer/
-> http://httpd.apache.org/docs-2.0/developer/thread_safety.html
That alrea
On Mon, 29 Nov 2004 22:36:01 -0500, Stas Bekman <[EMAIL PROTECTED]> wrote:
> Jeff Trawick wrote:
>
>
> > On Mon, 29 Nov 2004 17:16:31 -0500, Stas Bekman <[EMAIL PROTECTED]> wrote:
> >
> >>Jeff Trawick wrote:
> >>
> >>
> >>>How is SIGALRM used specifically?
> >>
> >>e.g.:
> >> eval {
> >>
Jeff Trawick wrote:
On Mon, 29 Nov 2004 17:16:31 -0500, Stas Bekman <[EMAIL PROTECTED]> wrote:
Jeff Trawick wrote:
How is SIGALRM used specifically?
e.g.:
eval {
POSIX::sigaction(SIGALRM,
POSIX::SigAction->new(sub { die "alarm" }))
On Mon, 29 Nov 2004 17:16:31 -0500, Stas Bekman <[EMAIL PROTECTED]> wrote:
> Jeff Trawick wrote:
>
> > How is SIGALRM used specifically?
>
> e.g.:
> eval {
> POSIX::sigaction(SIGALRM,
> POSIX::SigAction->new(sub { die "alarm" }))
>
Jeff Trawick wrote:
How is SIGALRM used specifically?
e.g.:
eval {
POSIX::sigaction(SIGALRM,
POSIX::SigAction->new(sub { die "alarm" }))
or die "Error setting SIGALRM handler: $!\n";
alarm 2;
potentially_lon
On Mon, 29 Nov 2004 16:16:09 -0500, Stas Bekman <[EMAIL PROTECTED]> wrote:
> Jeff Trawick wrote:
> > On Mon, 29 Nov 2004 13:24:29 -0500, Stas Bekman <[EMAIL PROTECTED]> wrote:
> >
> >>Is there some doc explaining the usage of signal handlers under different
> >>mpms?
> >
> >
> > No, although I woul
Cliff Woolley wrote:
On Mon, 29 Nov 2004, Stas Bekman wrote:
nuke it?
So this is incorrect?
- The MPM does not set a SIGALRM handler, user code may use SIGALRM.
It can use it if it knows what it's doing.
What do you mean?
A mod_perl module that's
expected to work on any MPM (which is I'm ass
Bill Stoddard wrote:
Stas Bekman wrote:
Jeff Trawick wrote:
On Mon, 29 Nov 2004 13:24:29 -0500, Stas Bekman <[EMAIL PROTECTED]> wrote:
Is there some doc explaining the usage of signal handlers under
different
mpms?
No, although I would suggest the following ;)
/* @tip Don't use signals in your o
Cliff Woolley wrote:
On Mon, 29 Nov 2004, Stas Bekman wrote:
nuke it?
So this is incorrect?
- The MPM does not set a SIGALRM handler, user code may use SIGALRM.
It can use it if it knows what it's doing.
Too much rope Cliff, too much rope. :-)
A mod_perl module that's
expected to work on an
On Mon, 29 Nov 2004, Stas Bekman wrote:
> nuke it?
>
> So this is incorrect?
>
> - The MPM does not set a SIGALRM handler, user code may use SIGALRM.
It can use it if it knows what it's doing. A mod_perl module that's
expected to work on any MPM (which is I'm assuming what you're talking
ab
Cliff Woolley wrote:
On Mon, 29 Nov 2004, Stas Bekman wrote:
./include/ap_mpm.h
unix/posix notes:
- The MPM does not set a SIGALRM handler, user code may use SIGALRM.
But the preferred method of handling timeouts is to use the
timeouts provided by the BUFF abstraction.
Tha
Stas Bekman wrote:
Jeff Trawick wrote:
On Mon, 29 Nov 2004 13:24:29 -0500, Stas Bekman <[EMAIL PROTECTED]> wrote:
Is there some doc explaining the usage of signal handlers under
different
mpms?
No, although I would suggest the following ;)
/* @tip Don't use signals in your own modules. Apache ma
On Mon, 29 Nov 2004, Stas Bekman wrote:
> ./include/ap_mpm.h
> unix/posix notes:
> - The MPM does not set a SIGALRM handler, user code may use SIGALRM.
> But the preferred method of handling timeouts is to use the
> timeouts provided by the BUFF abstraction.
That's an ancien
Jeff Trawick wrote:
On Mon, 29 Nov 2004 13:24:29 -0500, Stas Bekman <[EMAIL PROTECTED]> wrote:
Is there some doc explaining the usage of signal handlers under different
mpms?
No, although I would suggest the following ;)
/* @tip Don't use signals in your own modules. Apache makes no effort to
*
On Mon, 29 Nov 2004 13:24:29 -0500, Stas Bekman <[EMAIL PROTECTED]> wrote:
> Is there some doc explaining the usage of signal handlers under different
> mpms?
No, although I would suggest the following ;)
/* @tip Don't use signals in your own modules. Apache makes no effort to
* support modules
Is there some doc explaining the usage of signal handlers under different
mpms? I get SIGALRM working fine under prefork mpm, but not under worker.
I assume that it traps the signal before the user code's handler runs,
simple grepping doesn't come up with anything useful, so if someone who
unde
20 matches
Mail list logo
