harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [classlib][luni] socketus interruptus - fix committed
Date Fri, 08 Sep 2006 02:55:51 GMT


Jimmy, Jing Lv wrote:
> Geir Magnusson Jr. wrote:
>> I committed the initial fix to the socket interrupt problem.  I stared 
>> at it a while and did what I thought the simplest thing possible.  
>> (Most of the staring was trying to grok some of the intent in the 
>> socket.c and hysock.c code...
>>
>> Simply put, I ensured that hysock_select() just dealt w/ that return 
>> code correctly, translating to the HSOCK error code.  (I also did a 
>> bit of reformatting... apologies if it really upsets someone - I'll 
>> put it back).  The result is that hysock_select() still behaves the same.
>>
>> I also modified one function in socket.c - the pollSelectRead() call - 
>> to deal with the interrupt return code from hysock_select().
>>
>> I *think* I got it right, and am hoping that some others can review 
>> and comment.  I'm embarrassed to have used a 'goto' (mimicing the 
>> style there), but didn't want to do the rewrite I wanted to while also 
>> fixing the interrupt problem. :)  (I also want some better tests 
>> before we take it apart...)
>>
> 
> I've taken a quick review on the two files, and I like the reformatting 
> :) Maybe the "goto" can be avoid, but this does not matter much.

It can certainly be avoided, but I didn't want to change too much at 
this time.

> 
> I notice the port lib, say hysock.c is modified, adding a line:
>         if (errno == EINTR) {
>             rc = portLibrary->error_set_last_error(portLibrary, errno, 
>                                                       
> HYPORT_ERROR_SOCKET_INTERRUPTED);
>         }
> IMHO, we can avoid this modification, for method in socket.c the result 
> is judged by the return value("result"), not last_error. IMHO, we'd 
> better do no modification on port lib. Please correct me if I'm wrong.

Well, yes, it is judged by the return value, but if the semantics of 
hyscok_XXXX is that if there is an error, the platform error is set via 
_error_set_last_error, then I wanted to follow the convention.

This was one more thing to chase down- I figured I'd just follow along 
for now :)

> 
>> This of course fixes the problems w/ Tomcat that we created w/ the 
>> DRLVM thread manager fix, so I'm going to try to spin a new snapshot 
>> tonight.
>>
>> Also, I'll go and treat the other usages of hysock_select() to deal w/ 
>> this return code, but after there's been a period of review and 
>> comment for these changes.
>>
> 
> I have no objection if everything goes well, but still worry about how 
> to tell the difference between a necessary interruption(user 
> interruption) and this recover-able interruption.

I've been thinking about this a lot, and I just don't know.  There is no 
concept for this up in Java, so it's not like we're breaking anything there.

I do wonder if our concerns are overblown, that this is Just The Way 
Things Are due to the history of how IO calls and signals evolved in 
unix and linux.

But again, I'm not sure of myself here...

geir

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

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