4 ms·
The original codebase used asserts rather poorly, for error handling rather than internal sanity checks. Four years ago we had fixed most of these problems, and
by PieterH 11y ago
The original codebase used asserts rather poorly, for error handling rather than internal sanity checks. Four years ago we had fixed most of these problems, and had a "futzing" project to try to crash the library. Over time we've removed the edge cases... the codebase did take a long time to become properly stable, one of the downsides of lots of new code written rapidly, and one reason we insist on small gradual patches these days. (There have been _very_ few new errors introduced since we switched to our decentralized contribution process in early 2011.)
- mpdehaan2 11y agoGood to know. For what it's worth, the majority of my bad experiences were in 2013 to late 2014, and usually through the python bindings. Usually calling the functions in differnt ways was able to dodge the problem. It's not always quite obvious what caused it to crash, but it was sort of "if it hurts when you do that" sort of thing. Often these types of errors happened only under heavy traffic and were hard to replicate except under stress or lots of repeated calls. If not using the python bindings, it might be better off for most people.
- lobster_johnson 11y agoHas the problem with req/rep over lossy connections been solved (http://lucumr.pocoo.org/2012/6/26/disconnects-are-good-for-you/ http://lucumr.pocoo.org/2012/6/26/disconnects-are-good-for-y...)? My understanding was that you couldn't detect disconnects because ZMQ doesn't expose the internal state.