On 12/06/2019 08:46, Radovan Semancik wrote:
On 11. 6. 2019 18:49, Emmanuel Lécharny wrote:
The main issue is the fact the API is asynchronous. It makes
*everything* insanely complex. Anyone claiming concurrent code is
simple is either a genious or an imbecile.
Curious how thin can be a boundary between an imbecile and a genius,
isn't it?
Yep. Maybe that is because many people - very smart ones - are
advocating that async is the new normal, and many imbeciles just trust
them because they successfully built an 'hello world++" application
based on events...
But that vast majority of people are just struggling with the concepts,
and I would guess that 99.99% have never heard of Petri nets... (they
probably think it's a set of Petri boxes linked together ;-)
However, even if MINA is async in nature, the client is usually using
it is a very sync way.
Yes. And the API wraps all the operation as synchronous on top of
asynchronous operations. However, for the API implementer, you have to
take care of things like Abandon operation that could be done in the
middle of another operation. But from the client PoV, asynchronous is
just a burden, and the API could have been fully written using a
blocking socket.
As I said in a previous mail, we need to drink the async coolaid because
the server is using the API (first to process incoming requests, second
because we need to talk to other LDAP servers for replication,
delegated auth, or referrals handling). And then it's a very different
story: ApacheDS wouldn't have existed witjout NIO? simply because we
need to handle potentially millions of incoming connections, something
you can't do with blocking IO.
Opening connection, waiting, sending request, waiting for response and
so on. There is hardly any multiplexing. And if there is, it is not
essential for a basic use of the API. I'm thinking about a way how to
select sync implementation instead of MINA.
We started to work on implementing blocking IO in MINA 4 years ago.
Never completed the work. But yeah, basically, there is no reason a
network framework couldn't offer such a possibility.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
