You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "Geir Magnusson Jr." <ge...@pobox.com> on 2006/09/08 02:57:59 UTC
[classlib][luni] socketus interruptus - fix committed
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...)
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.
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
Re: [classlib][luni] socketus interruptus - fix committed
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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
Re: [classlib][luni] socketus interruptus - fix committed
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
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.
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.
> 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.
> 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
>
>
--
Best Regards!
Jimmy, Jing Lv
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