On Dec 7, 2010, at 9:40 AM, Scott Asher wrote: > I've run into this assertion occasionally when I close sockets. Questions > about both parts: > > 1) !more > > Why do you care if there is part of a multi-part message still left on the > pipe enough to assert about it? Maybe this should be a thrown error that can > be caught? In my case I hit this because in my messaging system I read a > header first, leaving the rest of the message on the pipe to be read slightly > later. Usually, the rest of the message does get read, but if my messaging > thread shuts down before I've read the rest of the message, it will trigger > this assert. To get around this I've had to catch my own interrupts and > manually drop data from the pipes, which seems like something I shouldn't > have to worry about? But maybe I'm missing something. > > 2) pipes [current] != pipe_ > > I've run into this a lot less often, but it happens really occasionally and > non-deterministically (which makes it very tough to debug). Figured I would > mention it in case anyone had comments (about what could be going on). If it > keeps up, I will try to produce a minimal test case. Will require me > understanding the underlying code stack a lot better.
I opened a ticket on this a week or so ago. https://github.com/zeromq/zeromq2/issues#issue/119 I see this assertion whenever I terminate (ctrl-c) my application while it is under load. This conforms to your statement about getting the assertion when your messaging thread shuts down while there are still message parts unread on the pipe. cr _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
