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