Re: gcj: SignalListener, process pid, ...

[Bryce McKinlay <bryce at mckinlay dot net dot nz>]

On Wednesday, Oct 1, 2003, at 07:01 Pacific/Auckland, Erik Poupaert 
wrote:

> > Oh dear.  That means to use a server process that can handle SIGHUP
> > you'll have to create a wrapper.
>
> I guess people traditionally use SIGHUP for instructing the server 
> process to reread
> its config files. Would it be acceptable in terms of linux/unix 
> conventions to use
> one of SIGINT, SIGQUIT, SIGUSR1,SIGUSR2, or SIGTERM signals? I mean, 
> in that case,
> I'll use one of these, instead of using a wrapper.

A simpler alternative may be to just check periodically to see if the 
date/time on the config file has changed, and if so, re-read it?

> By the way, if anybody has the expert knowledge of how to turn a 
> "pthread_t" into a
> corresponding"pid", please let me know. I'd be most grateful.

There isn't really a legal/portable way to do that. It happens that, on 
Linux, there is a 1:1 association between threads and PIDs. But, that 
is certainly not the case on other implementations of pthreads. So, 
getpid() is what you should use. If you want to signal a thread inside 
your application, you use pthread_kill which takes a pthread_t argument.

The "correct" POSIX behaviour is that if you signal a threaded 
application, it is undefined which thread actually receives that 
signal, although the application can set up per-thread signal masks 
(pthread_sigmask) to control this. Since libgcj is creating its own 
threads internally, it might be tricky.

Regards

Bryce.