| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
|
|
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.)
|
