| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This provides context support for REQ and REP sockets.
More discussion around this is in the issue itself.
Optionally we would like to extend this to the surveyor pattern.
Note that we specifically do not support pollable descriptors
for non-default contexts, and the results of using file descriptors
for polling (NNG_OPT_SENDFD and NNG_OPT_RECVFD) is undefined.
In the future, it might be nice to figure out how to factor in
optional use of a message queue for users who want more buffering,
but we think there is little need for this with cooked mode.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.)
|
