LinuxThreads

[Grisha Trubetskoy <gr...@verio.net>]

I apologize if this is the wrong forum for this question - any pointers
to a more appropriate discussion space would be appreciated.

I have developed a module that embeds Python within httpd (a la
mod_perl). On Linux, the process freezes (gdb will report something
about SIGUSR1 received) when a Python script attempts to create a new
thread, but everything works OK on Solaris.

I suspect it has something to do with LinuxThreads and Apache having
some sort of a conflict over SIGUSR1 because LinuxThreads uses SIGUSR1
for internal purposes, which is mentioned in the LT FAQ
http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html

My question is - does this sound like I identified the problem
correctly, is this a known limitation of Apache on Linux and are there
ways to get around this?

Thanks a lot for any comments,

Grisha Trubetskoy

Re: LinuxThreads

[Manoj Kasichainula <ma...@raleigh.ibm.com>]

On Sat, Dec 12, 1998 Grisha Trubetskoy wrote:
> Hmmm... I'm pretty sure I'm using glibc 2.0.7, only on Debian, and it
> still causes the problem. 

Dean knows kernel stuff 2000 times better than me, but I think that
threads under Linux require user signals unless you have kernel 2.1.x
or the hopefully-soon-to-be 2.2, because of the lack of POSIX signals
in 2.0. 

Re: LinuxThreads

[Dean Gaudet <dg...@arctic.org>]

On Sat, 12 Dec 1998, Grisha Trubetskoy wrote:

> 
> Thanks, Dean.
> 
> Hmmm... I'm pretty sure I'm using glibc 2.0.7, only on Debian, and it
> still causes the problem. 
> 
> I actually downloaded the glibc source and recompiled it replacing the
> SIGUSR1 and SIGUSR2 signals with SIGSTKFLT and SIGUNUSED as the
> LinuxThreads FAQ suggests and the problem did go away. 
> 
> Recomipling libc, however, didn't seem like a very practical way to
> solve a problem though...

Hmm.  glibc is supposed to use the posix realtime signal extensions which
give an "arbitrary" number of signals.  Maybe it only does that with a
2.1.x kernel though.

> Are there any plans to make Apache use other signals eventually?

No, this is a bug in linuxthreads/glibc which will resolve itself
eventually.

Dean

Re: LinuxThreads

[Grisha Trubetskoy <gr...@verio.net>]

Thanks, Dean.

Hmmm... I'm pretty sure I'm using glibc 2.0.7, only on Debian, and it
still causes the problem. 

I actually downloaded the glibc source and recompiled it replacing the
SIGUSR1 and SIGUSR2 signals with SIGSTKFLT and SIGUNUSED as the
LinuxThreads FAQ suggests and the problem did go away. 

Recomipling libc, however, didn't seem like a very practical way to
solve a problem though...

Are there any plans to make Apache use other signals eventually?

Grisha

Dean Gaudet wrote:
> 
> On Sat, 12 Dec 1998, Grisha Trubetskoy wrote:
> 
> > My question is - does this sound like I identified the problem
> > correctly, is this a known limitation of Apache on Linux and are there
> > ways to get around this?
> 
> Use glibc 2.x (i.e. redhat 5.x).  Or change apache to use something other
> than SIGUSR1 or SIGUSR2.
> 
> Dean

Re: LinuxThreads

[Dean Gaudet <dg...@arctic.org>]

On Sat, 12 Dec 1998, Grisha Trubetskoy wrote:

> My question is - does this sound like I identified the problem
> correctly, is this a known limitation of Apache on Linux and are there
> ways to get around this?

Use glibc 2.x (i.e. redhat 5.x).  Or change apache to use something other
than SIGUSR1 or SIGUSR2.

Dean