river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michał Kłeczek (XPro Sp. z o. o.)" <michal.klec...@xpro.biz>
Subject Re: Serialization issues
Date Sat, 04 Feb 2017 16:48:23 GMT
It is not possible to do non-blocking as in "non blocking IO" - meaning 
- threads do not block on IO operations.
Just google "C10K problem"

Thanks,
Michal

Niclas Hedhman wrote:
> I don't follow. What does readObject/writeObject got to do with blocking or
> not? You could spin up executors to do the work in parallel if you so wish.
> And why is "something else" less blocking? And what are you doing that is
> "blocking" since the "work" is (or should be) CPU only, there is limited
> (still) opportunity to do that non-blocking (whatever that would mean in
> CPU-only circumstance). Feel free to elaborate... I am curious.
>
>
>
> On Sat, Feb 4, 2017 at 8:38 PM, "Michał Kłeczek (XPro Sp. z o. o.)"<
> michal.kleczek@xpro.biz>  wrote:
>
>> Unfortunately due to "writeObject" and "readObject" methods that have to
>> be handled (to comply with the spec) - it is not possible to
>> serialize/deserialize in a non-blocking fashion.
>> So yes... - it is serialization per se.
>>
>> Thanks,
>> Michal
>>
>> Niclas Hedhman wrote:
>>
>> Oh, well that is not "Serialization" per se... No wonder i didn't get it.
>>
>> On Sat, Feb 4, 2017 at 7:20 PM, Peter<jini@zeus.net.au>  <jini@zeus.net.au>
 wrote:
>>
>>
>> On 4/02/2017 9:09 PM, Niclas Hedhman wrote:
>>
>>
>> but rather with the APIs - it is inherently blocking by design.
>>
>> I am not sure I understand what you mean by that.
>>
>>
>>
>> He means the client thread that makes the remote call blocks waiting for
>> the remote end to process the request and respond.
>>
>> Cheers,
>>
>> Peter.
>>
>>
>>
>>
>>
>
>


Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message