This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> 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?

It could be entire directories full of config info ...
 
> 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.

It looks as if multi-threading was added as an afterthought to an environment that
is actually oriented to multi-processing. As a result, the concept of "signal" was
more or less thrown out of the window, because it didn't fit any longer. At the same
time, signals really did have a useful function; a function that has not been taken
over by anything else. The end result is that the environment is now poorer and more
inconsistent than it used to be.

Ok. I'll just drop signals altogether, and fiddle with workarounds just like
everybody else.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]