aboutsummaryrefslogtreecommitdiff
path: root/src/protocol/pair/pair_v0.c
Commit message (Collapse)AuthorAge
* Eliminate legacy option settings, provide easier option IDs.Garrett D'Amore2017-08-24
| | | | | | | | | | | | | | | | | | This eliminates all the old #define's or enum values, making all option IDs now totally dynamic, and providing well-known string values for well-behaved applications. We have added tests of some of these options, including lookups, and so forth. We have also fixed a few problems; including at least one crasher bug when the timeouts on reconnect were zero. Protocol specific options are now handled in the protocol. We will be moving the initialization for a few of those well known entities to the protocol startup code, following the PAIRv1 pattern, later. Applications must therefore not depend on the value of the integer IDs, at least until the application has opened a socket of the appropriate type.
* Provide versions of mutex, condvar, and aio init that never fail.Garrett D'Amore2017-08-16
| | | | | | | | | | | | | | | | | | | | | | | 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.
* Add new PAIR_V1 protocol.Garrett D'Amore2017-08-10
The PAIR_V1 protocol supports both raw and cooked modes, and has loop prevention included. It also has a polyamorous mode, wherein it allows multiple connections to be established. In polyamorous mode (set by an option), the sender requests a paritcular pipe by setting it on the message. We default to PAIR_V1 now.