| Commit message (Collapse) | Author | Age |
| |
|
|
|
| |
This will allow us to use idhash to manage ephemeral ports (indexed
by port), while also allowing us to insert managed ports.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
We intend to use this with transports where dynamic "port numbers"
might be 32-bits. This would allow us to formulate a 64-bit number
representing a conversation, and be able to find that conversation
by the 64-bit value.
Note that the hashed values are probably not perfectly optimal, as
only the low order bits are particularly significant in the hash.
We might want to consider XOR'ing in the upper bits to address that.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 does a few things. First it closes some preexisting leaks.
Second it tightens the overall close logic so that we automatically
discard idhash resources (while keeping numeric values for next id
etc. around) when the last socket is closed. This then eliminates
the need for applications to ever explicitly terminate resources.
It turns out platform-specific resources established at nni_init()
time might still be leaked, but it's also the case that we now no
longer dynamically allocate anything at platform initialization time.
(This presumes that the platform doesn't do so under the hood when
creating critical sections or mutexes for example.)
|
| | |
|
| |
|
|
|
|
| |
This will allow us to use idhash tables to manage id handles a bit more
flexibly. For example, sockets, pipe IDs, etc. can all be generated, and
we can use hash tables to ensure that values do not collide.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|
|
We use some hints from Python's dict implementation, using an
open addressing scheme, and just ripping off the lower bits as
needed. Since we assign IDs consecutively, this should work
well. We shrink the table when it is only 1/8 full, and
we ensure that we grow the table when it is 2/3 full. (The
growth will start by at minimum doubling the required size.)
|