| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
| |
This fixes one major problem, which was that if nni_fini() was called
once on Windows, it would not be further possible to call nni_init().
While here fixed a few compilation issues.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
A little benchmarking showed that we were encountering far too many
wakeups, leading to severe performance degradation; we had a bunch
of threads all sleeping on the same condition variable (taskqs)
and this woke them all up, resulting in heavy mutex contention.
Since we only need one of the threads to wake, and we don't care which
one, let's just wake only one. This reduced RTT latency from about
240 us down to about 30 s. (1/8 of the former cost.)
There's still a bunch of tuning to do; performance remains worse than
we would like.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This passes valgrind 100% clean for both helgrind and deep leak
checks. This represents a complete rethink of how the AIOs work,
and much simpler synchronization; the provider API is a bit simpler
to boot, as a number of failure modes have been simply eliminated.
While here a few other minor bugs were squashed.
|
| |
|
|
|
|
| |
Apparently there are circumstances when a pipedesc may get orphaned form the
pollq. This triggers an assertion failure when it occurs. I am still
trying to understand how this can occur. Stay tuned.
|
| |
|
|
|
|
|
|
|
|
|
| |
We have seen leaks of pipes causing test failures (e.g. the Windows
IPC test) due to EADDRINUSE. This was caused by a case where we
failed to pass the pipe up because the AIO had already been canceled,
and we didn't realize that we had oprhaned the pipe. The fix is to
add a return value to nni_aio_finish, and verify that we did finish
properly, or if we did not then we must free the pipe ourself. (The
zero return from nni_aio_finish indicates that it accepts ownership
of resources passed via the aio.)
|
| | |
|
| |
|
|
|
|
| |
This logic leaves a race condition in the dial side, which will
be fixed with a subsequent change to convert that to fully asynchronous
as well.
|
| | |
|
| |
|
|
|
|
| |
This is only lightly tested, and I expect that there remain
some race conditions. Endpoint logic in particular needs
work.
|
| |
|
|
|
|
| |
We still have endpoint related races apparently; we need to examine
the possibility of handling endpoints much like we do pipes, which seem
to be race free.
|
| |
|
|
|
| |
We are still seeing likely errors with pipes outliving their associated
endpoints, so work is still needed here.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The IOCP code has been refactored to improve reuse, and hopefully
will be easier to use with TCP now. Windows IPC using Named Pipes
is mostly working -- mostly because there is a gnarly close-race.
It seems that we need to take some more care to ensure that the
pipe is not released while requests may be outstanding -- so some
deeper synchronization between the IOCP callback logic and the
win_event code is needed. In short, we need to add a condvar to
the event, and notice when we have submitted work for async completion,
and make sure we flag the event "idle" after either completion or
cancellation of the event.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Modern Windows (Vista and later) have light weight Slim Read/Write locks
which only occupy 64 bits, and don't require any memory allocation to
create.
While here clean up a few more unreferenced variables found with the
Microsoft compilers.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
I seem to be having a very difficult time getting dual-stack sockets
to function properly on Windows. I've sort of abandoned it for now.
I need to think about how to solve this -- it's not clear to me
right now whether dual stack sockets are the right answer or not.
People do expect these to work, but a tcp6:// url might be more
elegant.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Sleep() on Win32 rounds *down*, leading to truncated timeouts.
What we do is change our sleep routing to start incrementally
sleeping by 1ms until the tick count is reached. This ensures
we don't wake early.
This problem affects condition variables too, which means that some
timeouts may occur up to one clock tick early (15ish ms). This should
not be a problem for most users, who should really only be setting
timeouts in quantities of a second or greater.
|
| |
|
|
|
|
|
|
|
|
| |
This compiles correctly, but doesn't actually deliver events yet.
As part of this, I've made most of the initializables in nng
safe to tear-down if uninitialized (or set to zero e.g. via calloc).
This makes it loads easier to write the teardown on error code, since
I can deinit everything, without worrying about which things have been
initialized and which have not.
|
| | |
|
| | |
|
| |
|
|
|
| |
Test code needs to use the static libraries so that they can get access
to the entire set of symbols, including private ones that are not exported.
|
| |
|
|
|
|
| |
It turns out that I didn't quite understand overlapped I/O. We can and
should always do the GetOverlappedResult(), regardless of how the routine
returns.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Since we use the tick counter to sleep, we should use the same clock
for validation. The problem is that the high performance tick counter
on the CPU may be slightly out of agreement with the windows clock.
Furthermore, the tick counter is probably lots faster to retrieve since
it is already updated, and needn't be recalculated each time.
(We should consider just switching to millisecond clock resolution
internally as well. It turns out that I don't think that timers that
are shorter than 1ms are very useful.)
|
| |
|
|
|
|
|
| |
There are lots of changes here, mostly stuff we did in support of
Windows TCP. However, there are some bugs that were fixed, and we
added some new error codes, and generalized the handling of some failures
during accept. Windows IPC (NamedPipes) is still missing.
|
| |
|
|
|
|
| |
Windows is getting there. Needs a couple of more more hours to enable
everything, especially IPC, and most of the work at this point is probably
some combination of debug and tweaking things like error handling.
|
| |
|