[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interruption of InterruptibleChannel methods

From: Nicolas Geoffray
Subject: Re: Interruption of InterruptibleChannel methods
Date: Fri, 28 Oct 2005 12:27:55 +0200
User-agent: Mozilla Thunderbird 1.0.7 (X11/20051019)

Hi Tom,

Nicolas> I have the feeling that something has to be done inside gnu
Nicolas> classpath in order for a a vm to correctly deal with the
Nicolas> interruption of a thread inside an InterruptibleChannel
Nicolas> method.

At least in the unix ports of libgcj, Thread.interrupt sends a signal
to the target thread, the idea being that this will interrupt any
blocking I/O operation there.

I saw the implementation, the signal handler does nothing,
and the method that can receive the signal checks the thread
interrupt state. What if the java method that was
executing the i/o operation is not part of an
InterruptibleChannel class? Does gcj interrupt it too, or does
it mask the signal?

Furthermore, a developper that creates its own class extending
the InterruptibleChannel and has its own native calls (it doesn't
use the gcj native implementation of i/o operations), do we
(vm implementors) have to deal with it, in order, to have the
interrupt thing going well with it?

Nicolas> Is this kind of discussion present elsewhere? I didn't find
Nicolas> it in the archives. And the docs in gnu classpath and vms
Nicolas> seem like "forgiving" the issue.

This requirement (if it is one -- gcj goes its own way for the native
code and so I can't really speak for Classpath here) would be a great
addition to the VM integration documentation.

Apparently, the merge between gnu classpath and gcj doesn't
concern native code. I guess it would be easier if this interrupt
thing could be in classpath. Has anyone allready looked at it?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]