| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
This implements the basic UDP functionality for Windows (required
for ZeroTier for example). We have also introduced a UDP test suite
to validate that this actually works. While here a few Windows
compilation warnings / nits were fixed.
|
| |
|
|
|
|
|
|
|
| |
This moves the DNS related functionality into common code, and also
removes all the URL parsing stuff out of the platform specific code
and into the transports. Now the transports just take sockaddr's on
initialization. (We may want to move this until later.)
We also add UDP resolution as another separate API.
|
| |
|
|
|
|
|
|
|
|
| |
We only compile files that are appropriate for the platform. (We
still have guards in place, to allow for a future single .C file
to be built from all the sources.) We also remove the subsystem defines;
if a new platform needs to deviate from POSIX in ways beyond what we
intended here, then that platform should just copy those parts into
a new platform directory, rather than cross including portions from
POSIX.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the underlying platform fails (FreeBSD is the only one I'm aware
of that does this!), we use a global lock or condition variable instead.
This means that our lock initializers never ever fail.
Probably we could eliminate most of this for Linux and Darwin, since
on those platforms, mutex and condvar initialization reasonably never
fails. Initial benchmarks show little difference either way -- so we
can revisit (optimize) later.
This removes a lot of otherwise untested code in error cases and so forth,
improving coverage and resilience in the face of allocation failures.
Platforms other than POSIX should follow a similar pattern if they need
this. (VxWorks, I'm thinking of you.) Most sane platforms won't have
an issue here, since normally these initializations do not need to allocate
memory. (Reportedly, even FreeBSD has plans to "fix" this in libthr2.)
While here, some bugs were fixed in initialization & teardown.
The fallback code is properly tested with dedicated test cases.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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 is only lightly tested, and I expect that there remain
some race conditions. Endpoint logic in particular needs
work.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
