PATCH: Threads and SIGINT
Bryce McKinlay
bryce@albatross.co.nz
Thu Dec 23 13:02:00 GMT 1999
Tom Tromey wrote:
> Parts of it are ok: fixing the interrupted/isInterrupted semantics
> (this part is better than ok: it is required), the Boehm GC changes,
> the bug fix in Thread.join.
>
> Parts I like less. I don't like that the LINUX_THREADS define is used
> outside the posix-threads code. I think this imlementation detail
> should be kept entirely private to the posix threads code.
I agree - this particular #ifdef isn't required and it can be removed.
> There has to be some other way to do this. For instance, on non-Linux
> POSIX systems, we could record the condition variable when
> _Jv_CondWait is entered, and have _Jv_ThreadInterrupt notify this
> condition variable. Wouldn't that work? What do you think of this?
Unfortunatly, I don't think its that simple. For the wait() case, calling
cond_notify() requires that we hold the mutex corresponding to the
monitor that the target thread is waiting for. We can't guarantee that we
can get that mutex in a timely fashion, as other threads may be
contending for it and holding it. By the time we get it there may be a
completely different thread waiting, and we'd interrupt the wrong thread.
I'm sure a portable solution is possible, but it probibly won't be
particularly efficient, and will certainly require a lot of thinking and
rearranging of the existing threads code. I agree that the
interrupt-by-signal stuff is a bit of a hack, but it does get the job
done and I think it should go in, as an interim solution.
> I'd rather not use platform defines like "SOLARIS". I realize we do
> that for Linux, but that was a mistake. Instead we could have a
> define that would be used to disable HAVE_RECURSIVE_MUTEX, and define
> this define in configure.in when using Solaris.
Yes, that sounds much better.
regards
[ bryce ]
More information about the Java-patches
mailing list