Re: gEDA-user: PCB threads (was: PCB+GL Progress)

[Ineiev <ineiev@xxxxxxxxx>]

On 2/25/09, Peter Clifton <pcjc2@xxxxxxxxx> wrote:
> If you have a specific coding problem with PCB, lets discuss that. I'm
> not going to dig into threaded programming issues when we don't have to
> worry about them.

Yes, there is a problem, though I can't judge
if it should be worried about multithreading.

PCB sources hint that it would be good if the program made
a backup of the board before abnormal termination:
there is even a handler in error.c,
though it is never setup; and I think the latter
was a wise decision, because the handler invokes
non-async-safe functions (and the things are even
worse for non-POSIX environments).

Generally, the handler could be fixed for POSIX systems
without using extra libraries like pthreads, if PCB
were single-threaded; when the program is multi-threaded,
the handler may be reentered. I reproduce it like this:

#include<unistd.h>
#include<signal.h>
#include<pthread.h>
#include<stdio.h>
static void
handler(int sig)
{const char msg0[]="enter handler\n",
  msg1[]="cleanup complete\n";
 write(2,msg0,sizeof(msg0)-1);
 sleep(5);/*time to clean up*/
 write(2,msg1,sizeof(msg1)-1);
 signal(sig,SIG_DFL);raise(sig);
}
static void*
runner(void*p)
{
 sleep(3);
 raise(SIGINT);
 return p;
}
int
main(void)
{pthread_t thread;
 pthread_create(&thread,0,runner,0);
 signal(SIGINT,handler);
 sleep(2);
 raise(SIGINT);
 return 0;
}

I think in this case the solution has to include
some semaphores to lock at least the cleanup function
and probably also the board structures;
I can't tell how complicated it would be.

Regards,
   Ineiev.


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user