That sounds great! I will allocate a 'resource' for some testing.Thanks!
On Mon, Jul 17, 2017 at 9:46 PM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:
The libnng API right now offers some improvements for async I/O, but
really I think I’m going to be further enhancing it. Internally I have an
aio object (for async I/O), that allows one to submit an I/O operation and
get a callback executed when that operation is done. It supports having
automatic timeouts with operations, and cancellation as well. I’m pretty
sure that I’m going to clean this up a little bit, and promote it into a
user-facing API.
This will then be *vastly* simpler to integrate into event-driven
programming.
On Mon, Jul 17, 2017 at 6:42 PM SGSeven Algebraf <a1rex2003@xxxxxxxxx>
wrote:
Hi Garret,
Excellent news indeed!
My current situation is as follows. We are in an early production stage
where the nanomsg is a cornerstone of my communication schema to exchange
messages between different distributed processes.
I am finding the library quite useful. The heavy testing of nanomsg is
planned in a near future.
Nevertheless, some shortcomings around the 'nn_poll' (one bad socket
ruins all communication #$@! ) and lack of asynchronous, callback driven
API make things much harder then necessary :)
From my point of view, the only cumbersome/under-implemented part of
nanomsg is a mechanism of receiving on multiple sockets, not to mention the
inability of mixing them with 'normal' sockets or other events (timers,
event loops).
Performance is good. I am not putting much stress on the library, though.
Messages are small < 2k. Number of sockets is on a low side as well.
As the architect and the project lead, I am open to move to nng,
especially if it can make my life easier.
Your work and passion can only be admired!
I look <http://dictionary.cambridge.org/dictionary/english/look> forward
<http://dictionary.cambridge.org/dictionary/english/forward> to hearing
<http://dictionary.cambridge.org/dictionary/english/hearing> more good
news,
- Samuel
On Mon, Jul 17, 2017 at 6:19 PM, Garrett D'Amore <garrett@xxxxxxxxxx>
wrote:
Hi nanomsg fans,
I have some excellent news to report. I’ve finally gotten to the point
that I feel the major rework of the guts of libnng’s core are ready to be
merged into master. This replaces the entire thread-based architecture
with a fully asynchronous model, using either IO completion ports or
non-blocking I/O and poll (and in the future kqueue/epoll, etc.) as
appropriate for the platform.
Accordingly, I’ve merged the asyncpolled branch into master. (The
pre-merge state was saved as a tag called “threaded”, in case anyone wants
to compare.)
The code now passes all tests consistently, including a new
“scalability” test that opens up 2000 sockets (and does a REQ/REP exchange
on them) without too much difficulty.
None of this work would have been possible without the very generous
sponsorship of Capitar IT Group; they’ve sponsored this work, and are
funding further enhancements of libnng with an intent to invest further in
the nanomsg community. Please join me in thanking them for their
sponsorship and commitment to open source development!
There’s a bit of performance work still to be done, as there are many
opportunities to enhance the stack, and there are still some big
unimplemented areas — for example WebSockets are not implemented, and a
number of particular option setting things are missing as are statistics
reporting. Only the performance stuff should have a noticeable impact on
the core (and that won’t change any APIs, although I may expose some a very
nice asynchronous, callback driven, API to make life easier — and faster! —
for folks integrating into 3rd party event loops and such). As such, I
feel good about recommending folks start playing around with this; I’m
ready to begin soliciting feedback, and encourage folks to begin filing
issues against the nng bug tracker. If folks want to contribute other
things in the form of PRs, that’s welcome at this point too.
I do ask for some more patience as I work on the next steps to further
enhance performance and do some level of bug fixing such as fixing some
small memory leaks.
Thank you all for your patience during this rather long development
process!
- Garrett
