You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Regis <xu...@gmail.com> on 2009/07/07 07:30:36 UTC
Should we set tcp_nodelay true for Pipe.SinkChannel
Hi,
As we known, Harmony used loop socket to implement j.n.c.Pipe. On some
platforms, data written from one socket side would not send to other side
immediately, that cause data delay in our Pipe.
It's a problem in o.a.h.nio.internal.SelectorImpl, which used Pipe to wake up
blocked select, so if the delay happened, select would not be interrupted, even
Selector.wakeup() has finished. So I propose that setting tcp_nodelay to true
for Pipe.SinkChannel to help this. I'm not sure whether this change may affect
Pipe performance because of not using socket buffer. What do you think?
--
Best Regards,
Regis.
Re: Should we set tcp_nodelay true for Pipe.SinkChannel
Posted by Regis <xu...@gmail.com>.
Tim Ellison wrote:
> On 07/Jul/2009 06:30, Regis wrote:
>> As we known, Harmony used loop socket to implement j.n.c.Pipe. On some
>> platforms, data written from one socket side would not send to other
>> side immediately, that cause data delay in our Pipe.
>>
>> It's a problem in o.a.h.nio.internal.SelectorImpl, which used Pipe to
>> wake up blocked select, so if the delay happened, select would not be
>> interrupted, even Selector.wakeup() has finished. So I propose that
>> setting tcp_nodelay to true for Pipe.SinkChannel to help this. I'm not
>> sure whether this change may affect Pipe performance because of not
>> using socket buffer. What do you think?
>
> Just checking, do you mean setting the TCP_NODELAY only on the socket
> that you are using to wake up the select() or on all Pipe sockets?
On all Pipe sockets, selector.wakeup() is just the case how I found this problem.
>
> Regards,
> Tim
>
>
>
--
Best Regards,
Regis.
Re: Should we set tcp_nodelay true for Pipe.SinkChannel
Posted by Tim Ellison <t....@gmail.com>.
On 07/Jul/2009 06:30, Regis wrote:
> As we known, Harmony used loop socket to implement j.n.c.Pipe. On some
> platforms, data written from one socket side would not send to other
> side immediately, that cause data delay in our Pipe.
>
> It's a problem in o.a.h.nio.internal.SelectorImpl, which used Pipe to
> wake up blocked select, so if the delay happened, select would not be
> interrupted, even Selector.wakeup() has finished. So I propose that
> setting tcp_nodelay to true for Pipe.SinkChannel to help this. I'm not
> sure whether this change may affect Pipe performance because of not
> using socket buffer. What do you think?
Just checking, do you mean setting the TCP_NODELAY only on the socket
that you are using to wake up the select() or on all Pipe sockets?
Regards,
Tim