| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
| |
Also, some instances nni_aio are changed to nng_aio. We think we want to harmonize
some of these types going forward as it will reduce the need to include headers
hopefully letting us get away with just "defs.h" in more places.
|
| |
|
|
|
|
|
|
|
| |
The use of task_abort to prematurely fail an aio at scheduling
time was a mistake, because it could have led to duplicate calls
to nng_aio_finish(). We do need to ensure that we leave an indicator
so that nni_aio_schedule can return the abort status to caller,
in the case that abort is called between the nni_aio_begin and
nni_aio_schedule calls.
|
| |
|
|
|
| |
Make sure *everything* is drained before proceeding all the way
to deallocation.
|
| |
|
|
|
|
|
|
|
| |
Applications must now call nng_init(), but they can supply
a set of parameters optionally. The code is now safe for
multiple libraries to do this concurrently, meaning nng_fini
no longer can race against another instance starting up.
The nni_init checks on all public APIs are removed now.
|
| | |
|
| |
|
|
|
|
|
| |
This introduces a new API, nng_aio_busy(), that can be used
to query the status of the aio without blocking.
Some minor documentation fixes are included.
|
| |
|
|
| |
fixes #1219 nng_close occasionally hang on Windows
|
| | |
|
| |
|
|
|
|
|
|
| |
This changes the array of flags, which was confusing, brittle, and
racy, into a much simpler reference (busy) count on the task structures.
This allows us to support certain kinds of "reentrant" dispatching,
where either a synchronous or asynchronous task can reschedule / dispatch
itself. The new code also helps reduce certain lock pressure, as a bonus.
|
| |
|
|
|
|
| |
While here I also improved the taskq.h comments (and removed a
stale prototype for nni_task_cancel), and addressed leaks in
the reqstress and multistress test programs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #326 consider nni_taskq_exec_synch()
fixes #410 kqueue implementation could be smarter
fixes #411 epoll_implementation could be smarter
fixes #426 synchronous completion can lead to panic
fixes #421 pipe close race condition/duplicate destroy
This is a major refactoring of two significant parts of the code base,
which are closely interrelated.
First the aio and taskq framework have undergone a number of simplifications,
and improvements. We have ditched a few parts of the internal API (for
example tasks no longer support cancellation) that weren't terribly useful
but added a lot of complexity, and we've made aio_schedule something that
now checks for cancellation or other "premature" completions. The
aio framework now uses the tasks more tightly, so that aio wait can
devolve into just nni_task_wait(). We did have to add a "task_prep()"
step to prevent race conditions.
Second, the entire POSIX poller framework has been simplified, and made
more robust, and more scalable. There were some fairly inherent race
conditions around the shutdown/close code, where we *thought* we were
synchronizing against the other thread, but weren't doing so adequately.
With a cleaner design, we've been able to tighten up the implementation
to remove these race conditions, while substantially reducing the chance
for lock contention, thereby improving scalability. The illumos poller
also got a performance boost by polling for multiple events.
In highly "busy" systems, we expect to see vast reductions in lock
contention, and therefore greater scalability, in addition to overall
improved reliability.
One area where we currently can do better is that there is still only
a single poller thread run. Scaling this out is a task that has to be done
differently for each poller, and carefuly to ensure that close conditions
are safe on all pollers, and that no chance for deadlock/livelock waiting
for pfd finalizers can occur.
|
| | |
|
| |
|
|
|
|
|
| |
The queue is bound at initialization time of the task, and we call
entries just tasks, so we don't have to pass around a taskq pointer
across all the calls. Further, nni_task_dispatch is now guaranteed
to succeed.
|
| |
|
|
|
|
|
|
| |
We have seen some yet another weird situation where we had an orphaned
pipe, which was caused by not completing the callback. If we are going
to run nni_aio_fini, we should still run the callback (albeit with a
return value of NNG_ECANCELED or somesuch) to be sure that we can't
orphan stuff.
|
| | |
|
| | |
|
| | |
|
| |
|
