Don't know about other serialization uses but my issue with it is that
it precludes using it in non-blocking IO.
Sorry if I haven't been clear enough.
Thanks,
Michal
Niclas Hedhman wrote:
And what I/O (network I/O I presume) are you doing during the serialization
(without RMI)?
On Sun, Feb 5, 2017 at 12:48 AM, "Michał Kłeczek (XPro Sp. z o. o.)"<
michal.klec...@xpro.biz> wrote:
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.klec...@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<j...@zeus.net.au> <j...@zeus.net.au>
<j...@zeus.net.au> <j...@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.
