harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
Date Tue, 20 Jun 2006 01:14:26 GMT
Archie Cobbs wrote:
> Paulex Yang wrote:
>> I. B send interrupt signal to A, and A responses by doing right thing
>> II. For select(), using signal to wake it up, and 
>> AbstractSelector.begin()/end() actually don't need to do much things
>> III. For blocking I/O, begin()/end() should set/reset some 
>> per-thread(IIUC, ThreadLocal) flags, when the thread is wakeup from 
>> I/O, the I/O classlib native codes checks the flags, if it is set, 
>> then the I/O is "interruptible" and everything is OK so just going 
>> on, but if not, which means the I/O is actually not "interruptible", 
>> so that the I/O classlib native codes should invoke the I/O system 
>> call again to blocking again.
>>
>> But the issues are:
>> a. for I, and I'm not sure how to wake up windows thread blocking on 
>> I/O, except close the file descriptor
>> b. for II, I have no idea how to wake up a Windows thread blocking on 
>> select, except secret wake up fd, or loop in Java codes with 
>> select(timeout)
>> c. for III, this solution impacts much to most I/O codes, first, it 
>> is hard for begin()/end() to encapsulate the machinery, every 
>> blocking I/O system call invocation must take care of the 
>> interruptible flag. And more significant, it is difficult to extend 
>> the AbstractInterruptibleChannel like spec requires, because at first 
>> the developer should care about the flags and make his I/O codes 
>> loop, and then he must know about the flags, because begin()/end() is 
>> final, so that it is impossible except we introduce more contract to 
>> Harmony users besides Java spec.
>
> For (a) and (b), the POSIX pthread_kill() function would work... but
> of course that requires POSIX compatibility 
Indeed.
> (this doesn't seem like
> a big requirement to me but then again I don't program on Windows).

> But I don't understand (c): every blocking I/O call is implemented
> in classlib native code, so the Java developer is not involved (the
> looping, checking of flags, etc. would be done in the native I/O code).
The AbstractInterruptibleChannel is open for Harmony user to extend, 
which means, the end user should can simply extend the class and create 
his own interruptible channel. Although I think this case is probably 
less than 0.1% of all Java application, but it's class library, so we 
never know how it is used, IMO that's one important reason of why we 
stick to the compatibility with spec and RI.
>
> To me it boils down to whether we can assume POSIX siganls are
> available. If not, then I agree we need the "interrupt actions".
>
>> 1. add a setInterruptAction(Runnable action), its implementation is 
>> straightforward
>> 2. Thread.interrupt() is supposed to be like this:
>> public void interrupt(){
>>    if(interruptAction != null){
>>       interruptAction.run();
>>    }
>>    interruptImpl();//do what it supposed to do before interruptible 
>> NIO world.
>> }
>
> OK, this is nice and simple.. installing an interrupt action is a clean
> and Java-centric way to make the handling of interrupts explicit. It may
> be technically unnecessary (if POSIX signals were available) but has
> the advantage of being less tied to the O/S and VM internals.
Great, so may I assume you agree with the VMI modification to add 
Thread.setInterruptAction()?
>
> -Archie
>
> __________________________________________________________________________ 
>
> Archie Cobbs      *        CTO, Awarix        *      
> http://www.awarix.com
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Paulex Yang
China Software Development Lab
IBM



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message