ZeroMq IRC Log

Sunday May 8, 2011

[Time] Name	Message
[07:08] CIA-75	libzmq: 03Pieter Hintjens 07master * rda1ef4d 10/ (src/rep.cpp src/xrep.cpp src/xrep.hpp): Fixed REP assert on missing envelope ...
[07:09] CIA-75	libzmq: 03Martin Sustrik 07master * r4938787 10/ (src/err.cpp src/err.hpp src/tcp_connecter.cpp): Async connect doesn't fail on EWSANETDOWN ...
[07:45] jond	sustrik: not sure you've read that patch i sent correctly.....
[08:06] sustrik	jond: hi
[08:06] sustrik	which part?
[08:06] sustrik	you mean this one: outpipes.erase (it++);
[08:06] sustrik	the compiler translates that to: outpipes.erase (it); it++;
[08:06] jond	sustrik: him the associative (map), yes
[08:07] jond	sorry that was mean to be hi
[08:07] sustrik	:)
[08:08] jond	the post increment should return a copy of the original value
[08:08] sustrik	sure
[08:08] sustrik	the problem is that erase invalidates iterators
[08:08] sustrik	all iterators
[08:08] sustrik	for example, if the underlying array is reallocated
[08:09] jond	yes that's why on vector erase should return the new iterator but
[08:09] sustrik	it's a problem with old HP implementation of STL
[08:09] sustrik	it does not return the iterator
[08:09] sustrik	it's pretty annoying
[08:10] sustrik	what about using remove_if?
[08:11] jond	the outpipes case however is correct. erase is not being passed iter, it is being passed a copy, the iterator has been moved before the call
[08:11] jond	gcc seems to be going the correct things
[08:11] sustrik	imagine this scenario:
[08:11] sustrik	it points to memory at 0x1000
[08:12] jond	are we talking about a map or vector?
[08:12] sustrik	vector
[08:12] sustrik	it's a map there?
[08:12] jond	outpipes is a map, inpipes is a vector. this is why I think you misread the patch
[08:13] sustrik	right
[08:13] jond	inpipes code needs work around if vector::erase doesnt return the new iterator
[08:14] jond	but as it stands i believe the patch is correct c++
[08:16] sustrik	hm
[08:17] sustrik	imo what happens is:
[08:17] sustrik	cope of it is made
[08:17] sustrik	one copy is passed to erase
[08:17] sustrik	which invalidates both copies of the iterator
[08:17] sustrik	then ++ is done on already invalid iterator
[08:18] sustrik	what can be done is something like this:
[08:18] sustrik	iterator tmp = it;
[08:18] sustrik	tmp++;
[08:18] sustrik	erase (it);
[08:18] sustrik	it = tmp;
[08:20] jond	I really believe in the outpipes case it should be safe to do outpipes.erase(iter++), isnt it effectively the same?
[08:22] sustrik	what outpipes(it++) does IMO is this:
[08:22] jond	josuttis : page 205 in my copy does it the same way for maps......
[08:22] sustrik	iterator tmp = it;
[08:22] sustrik	erase(it);
[08:22] sustrik	tmp++;
[08:22] sustrik	it = tmp;
[08:24] jond	i think for maps it's safe!
[08:25] jond	sustrik: I've gotta go now, but maybe it's worth getting some input on the mailing list??
[08:28] sustrik	ISO C++ should be consulted
[08:29] sustrik	exact semantics of postfix ++
[08:30] sustrik	"When a postfix operator is applied to a function argument, the value of the argument is not guaranteed to be incremented or decremented before it is passed to the function. See section 1.9.17 in the C++ standard for more information."
[09:19] jond	sustrik: good find. so 1) we are in agreement these iterators in two cases need fixing. map one can be solved by order of increment, vector perhaps using remove_if
[09:50] sustrik	jond: yes, agreed
[11:07] mikko	pieterh: overall the issue tracker is now better
[11:07] mikko	(github)
[11:14] mikko	i've been using cmake lately and it seems a lot nicer than autotools
[11:19] jond	sustrik: actually the outpipes case is redundant. once element to erase is found it returns anyhow and no further iteration happens.....
[11:22] jond	sustrik: as is the inpipes as far I can tell , it's only really an issue if you intend to continue the iteration post erase
[11:22] mikko	odd that cppcheck doesn't complain about it
[12:31] pieterh	mikko: hi
[12:33] mikko	hey
[12:36] mikko	17:33 at brussels tomorrow
[12:37] iFire	is there a survey of what people use for zeromq message encoding
[12:38] pieterh	mikko: cool, small meetup tomorrow evening then
[12:38] pieterh	mikko: you staying at my place?
[12:39] guido_g	is this meetup a public one?
[12:40] pieterh	guido_g: I'd guess so, yes
[12:40] guido_g	iFire: not that i know of, most people use the serialization that's best for their tool-chain
[12:40] guido_g	pieterh: ah great
[12:40] pieterh	guido_g: you'll be in Brussels tomorrow evening?
[12:41] pieterh	excellent!
[12:42] guido_g	i guess it'll take me an hour or so to get to th hotel
[12:43] pieterh	demarkten has wifi, not a bad place to work
[12:43] guido_g	i personally prefer cable but wifi sounds good :)
[12:44] pieterh	you can come to work at iMatix if you like
[12:45] pieterh	We can meet at 2pm or so at demarkten and then walk back to iMatix
[12:45] pieterh	it's about 10 minutes by foot
[12:45] guido_g	ah ok
[12:46] pieterh	it's a little out of the way
[12:47] guido_g	hmmm... no address in the imatix.com site
[13:00] pieterh	indeed... I removed that, have added it back again on contact page
[13:00] guido_g	ahh cool
[13:01] guido_g	too much people comming in i guess :)
[13:10] mikko	pieterh: yes, staying at yours if that's ok
[13:10] mikko	pieterh: do you want me to bring linen?
[13:10] pieterh	mikko: sure, if it's not a bother
[13:19] mikko	pieterh: will do
[13:20] pieterh	mikko: great... mato will also be staying at my place
[13:20] pieterh	i've tweeted a meetup at 7pm in town
[13:20] mikko	do i come straight to yours?
[13:20] mikko	is it far from brussels midi?
[13:21] pieterh	you can take a metro from brussels midi, it'
[13:21] pieterh	it's too far to walk
[13:21] pieterh	metro to yzer, then by foot
[13:22] pieterh	you're traveling alone, I guess?
[13:29] mikko	yes
[13:29] mikko	i'm alone
[13:33] pieterh	ok, if you get lost beep me on +32 475 235 984, and I'll come pick you up / find you
[13:38] guido_g	google maps is funny, it shows the Rue de Ateliers label only if i zoom in to the maximum, otherwise only the dutch name is visible
[13:38] guido_g	will be fun to navigate... :)
[22:00] notostraca	I'm a little confused about 0MQ
[22:01] notostraca	Could it work with something like Flash Sockets or Socket.IO on the client side, in the browser?
[22:02] notostraca	I'm fairly new to networking in general, but 0MQ looks like it might be better than the alternatives (by a lot)
[22:02] notostraca	hey mikey_w
[22:03] mikey_w	Hello
[22:15] jer	notostraca, could i'm sure, however, it's my experience that you don't want to have 0mq facing outwards -- i.e., where anybody might be able to connect to it. if they don't speak the 0mq protocol properly, the listening endpoint could die hitting an assert()
[22:16] jer	which wouldn't be a problem normally, except there are all sorts of garbage fed to all sorts of listening ports on the internet -- just check an http server log sometime =p