gcj: SignalListener, process pid, ...
Wed Oct 1 00:02:00 GMT 2003
On Wednesday, Oct 1, 2003, at 07:01 Pacific/Auckland, Erik Poupaert
>> 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.
More information about the Java