Salut,
charlie hunt wrote:
> I'm not sure I agree with the suggested change. ;-)
>
> With 'nWrite == 0', you will reregister the key when no additional bytes
> are written. In other words, as long as more than 0 bytes have been
> written you'll continue to write. Only when it says it can't write any
> additional bytes will the key be re-registered.
>
> The main reason I'm disagreeing has to do with the potential cost of
> re-registering, parking & unparking a thread being much greater than
> spending a few more cpu cycles to keep writing as long as bytes are
> successfully written.
>
> Fwiw, it can take upwards of 50,000+ cpu cycles to go through the park /
> unpark.
>
> I think before blindly putting in the change I'd recommend we do some
> performance & scalability tests including some stress tests that have
> some really large ByteBuffer writes, (on the order of 100k sized
> ByteBuffer).
>
> Note: My argument is analogous to spinning on a mutex versus
> immediately sleeping when trying to obtain a lock. You will most often
> acquire the lock much quicker by spinning some number of cycles versus
> going to sleep and then being waken.
One alternative is to loop over the socketChannel.write(bb) and exit
only when nWrite == 0 || !bb.remaining() like we are doing when we use
the temporary selector trick. What do you think?
-- Jeanfrancois
>
> charlie ...
>
> Jeanfrancois Arcand wrote:
>> Hi Karsten,
>>
>> Karsten Ohme wrote:
>>> Hi,
>>>
>>> in TCPConnectorhandler in the read and write methods the key is only
>>> reattached if 0 is returned by the read and write method. It would
>>> make more sense if the key is reregistered if not all remaining bytes
>>> are written.
>>>
>>> instead of:
>>>
>>> if (nWrite == 0){
>>> key.attach(callbackHandler);
>>> selectorHandler.register(key,SelectionKey.OP_WRITE);
>>> }
>>> better:
>>>
>>> if (byteBuffer.hasRemaining()){
>>> key.attach(callbackHandler);
>>> selectorHandler.register(key,SelectionKey.OP_WRITE);
>>> }
>>
>> I agree. Will apply your patch.
>>
>> Thanks
>>
>> -- Jeanfrancois
>>
>>
>>>
>>> Regards,
>>> Karsten
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net