bug with pthreads in red hat linux 5.0?

bug with pthreads in red hat linux 5.0?

Post by ian a. mas » Tue, 02 Jun 1998 04:00:00



for some strange reason in red hat linux
handling SIGUSR1 causes pthread_create to hang.

EXAMPLE:

#include <stdio.h>
#include <pthread.h>
#include <signal.h>

void signal_handler(int signo){
  fprintf(stderr, "got a %d\n", signo); }

void *signal_thread(void *arg){

Quote:}

main(){
  pthread_t  signal_tid;
  struct sigaction my_action;  

  my_action.sa_handler = signal_handler;
  sigemptyset(&my_action.sa_mask);
  my_action.sa_flags = 0;
  sigaction(SIGUSR1,&my_action, NULL);

  fprintf(stderr, "here 1\n");

  pthread_create(&signal_tid,
                 NULL,
                 signal_thread,
                 (void *)NULL);

  fprintf(stderr, "here 2\n");

Quote:}

will print out only the first here. why?
 
 
 

bug with pthreads in red hat linux 5.0?

Post by Chris Smit » Tue, 02 Jun 1998 04:00:00



> for some strange reason in red hat linux
> handling SIGUSR1 causes pthread_create to hang.

This problem is explained in the LinuxThreads FAQ... the implementation required
two signals, and so SIGUSR1 and SIGUSR2 are used.  If you need the signals, the
FAQ contains a description of how you can recompile the library to use different
signals that are defined, but aren't currently used.  Of course, this would be
risky for forward compatibility, but if you need those signals, you have little
choice.

-------------------------------------------------------------------------------
           Chris Smith          |      In reality, there has been only one
     University of Oklahoma     |     Christian, and he died on the cross.

-------------------------------------------------------------------------------

 
 
 

bug with pthreads in red hat linux 5.0?

Post by Miquel van Smoorenbu » Thu, 11 Jun 1998 04:00:00




Quote:

>for some strange reason in red hat linux
>handling SIGUSR1 causes pthread_create to hang.

SIGUSR1 and SIGUSR2 are used internally. Don't use them or it will
result in undefined behaviour (like your program forking off a copy
of nethack, who knows..)

Mike.
--
 Miquel van Smoorenburg | Our vision is to speed up time,

 
 
 

bug with pthreads in red hat linux 5.0?

Post by Peters, Mat » Thu, 11 Jun 1998 04:00:00


If you are using linuxthreads by Xavier Leroy, he uses SIGUSR
to do some synchronization.  Your thread manager will hang if
you set up your own handler.

> -----Original Message-----


> Posted At: Monday, June 01, 1998 12:20 AM
> Posted To: threads
> Conversation:      bug with pthreads in red hat linux 5.0?
> Subject:   bug with pthreads in red hat linux 5.0?

> for some strange reason in red hat linux
> handling SIGUSR1 causes pthread_create to hang.

> EXAMPLE:

> #include <stdio.h>
> #include <pthread.h>
> #include <signal.h>

> void signal_handler(int signo){
>   fprintf(stderr, "got a %d\n", signo); }

> void *signal_thread(void *arg){

> }

> main(){
>   pthread_t  signal_tid;
>   struct sigaction my_action;  

>   my_action.sa_handler = signal_handler;
>   sigemptyset(&my_action.sa_mask);
>   my_action.sa_flags = 0;
>   sigaction(SIGUSR1,&my_action, NULL);

>   fprintf(stderr, "here 1\n");

>   pthread_create(&signal_tid,
>             NULL,
>             signal_thread,
>             (void *)NULL);

>   fprintf(stderr, "here 2\n");

> }

> will print out only the first here. why?

 
 
 

1. Semaphore bug in Red Hat Linux?

Hello,
I am getting strange results when I run the following program (which works
fine under Solaris) on Red Hat Linux 6.1 (on a pentium machine).  A
semaphore is declared and initialized using values supplied on the command
line.  The first argument on the command line specifies whether the
semaphore should be shared or not and the second argument specifies the
initial value of the semaphore.  Strangely enough, when the first argument
is "1", which indicates a shared semaphore, the value of the semaphore does
not seem to initialize properly.  Also, the results differ when the
semaphore is declared globally versus locally (but the initialization does
not occur properly either way).  Can anyone explain this?

Any insight would be greatly appreciated.

- Nic

/* use -lrt flag when compiling  */
#define DIE(err) { fprintf(stderr, "%s\n", err); exit(1); }
#include <semaphore.h>
#include <stdio.h>
#include <stdlib.h>

sem_t sem;

int main(int argc, char *argv[])
{
  int val, shared;

  if (argc < 3)
    DIE("Usage: $ prodcon [shared] [initval]");

  shared = atoi(argv[1]);
  val = atoi(argv[2]);

  sem_init(&sem, shared, val);
  sem_getvalue(&sem, &val);
  printf("Semaphore value is %d.\n", val);
  sem_destroy(&sem);

  exit(0);

2. Help with Themes

3. pthread_joining on LINUX (red hat 6.2)

4. Msn Help

5. find a fullpath of a file in linux red hat 7.2

6. Windows 95 painful in 8MB

7. Threads programming for LINUX - Red Hat - Searching for documentation

8. Internal Battery for Toshiba T1900C

9. CodeWarrior for Red Hat Linux

10. pthreads on Red Hat

11. Red Hat pthreads/win32

12. C++ pthreads (Red Hat 6.0)

13. Red Hat machine CPU is consumed by a single process