ZeroMq IRC Log

Saturday November 13, 2010

[Time] Name	Message
[12:33] mikko	morning
[12:33] mikko	mato: are you there?
[12:58] Guthur	Is there a way to safe way to stop a ZMQ device
[12:59] Guthur	s/a safe way
[12:59] mikko	what do you mean by safe?
[12:59] mikko	you could send kill signal
[12:59] Guthur	Preferably not that way, hehe
[13:00] Guthur	say I have a program using a device, but want to stop the device and rebind the endpoints
[13:00] mikko	what happens if you send HUP?
[13:00] mikko	if you just want to rebind
[13:01] Guthur	So in the actual program would I just kill the thread it's running on and start again?
[13:01] mikko	i don't know whether there is a clean way
[13:02] Guthur	Do you feel it would be useful, or am I verging towards over-engineering?
[13:05] Guthur	I suppose its more a specialized device
[13:05] Guthur	It would probably require a kill signal socket to offer the cleanest approach
[15:16] sustrik	Guthur: the devices is an area where 0MQ can expand in different ways
[15:16] sustrik	you may add all kinds of features
[15:16] sustrik	stop signal
[15:17] sustrik	monitoring
[15:17] sustrik	dynamic configuration of sockets
[15:17] sustrik	etc.
[15:17] Guthur	sustrik, Do you see 0MQ p
[15:17] Guthur	oops ignore that
[15:17] Guthur	got a little trigger happy
[15:18] Guthur	sustrik, Do you see a 0MQ device project starting at some point, or would it just be left to the users?
[15:18] Guthur	Or would it go into the main 0MQ project
[15:18] sustrik	Guthur: i would say that in the future the devices should be separated from 0mq core
[15:19] Guthur	I would have to agree
[15:19] sustrik	same way as network switches and routers are different from clinet TCP/IP stack
[15:19] Guthur	I see to many projects grow well beyond their initial scope
[15:19] Guthur	feature creep is a real danger with projects
[15:19] sustrik	the thing with devices is that I think there is a lot of space for market segmentation
[15:20] sustrik	from very simple devices like the ones now in the core
[15:20] sustrik	to complex enterprise-grade servers
[15:21] sustrik	but yes, the short-term goal is to keep the feature creep to minimum
[15:23] mikko	sustrik: i got fairly massive patch for the builds
[15:23] mikko	i wonder what would be the best way to do this
[15:24] mikko	maybe if mato has time to review the changes at some point?
[15:24] mikko	https://gist.github.com/51b70e52d845fd64a91a
[15:24] mikko	gotta run ->
[15:24] sustrik	mikko: thx
[15:24] sustrik	i'll poke mato
[15:25] sustrik	but he's finishing some deadline right now afaik
[15:25] sustrik	mikko: why not send the patch to the ML?
[15:28] Guthur	sustrik, Do you don't think that such simplistic devices that have been added to 0MQ are of limited worth with the main OMQ lib
[15:29] sustrik	yes
[15:29] sustrik	they are they just as examples
[15:29] Guthur	s/don't/not
[15:30] sustrik	presumably, they will be removed in 3.0
[15:30] Steve-o	mikko: how are you finding Sun ONE also requires __asm__? Is that also a strict mode?
[15:30] sustrik	by that time we'll have some sane devices outside of 0mq core imo
[15:30] Guthur	sustrik, ack
[15:36] mikko	Steve-o: yes, strict mode
[15:37] mikko	Steve-o: apparently "for ANSI C applications use __asm__"
[15:37] mikko	can't remember where i read that
[15:37] Steve-o	I'm checking their blogs and they use "asm" everywhere, ugh
[15:37] mikko	"If you are writing a header file that will be included in ANSI C programs, use '__asm__' instead of 'asm' and '__volatile__' instead of 'volatile'."
[15:37] mikko	http://mspgcc.sourceforge.net/manual/c1308.html
[15:38] Steve-o	The volatile comment is out of date
[15:38] mikko	yes
[15:39] mikko	__asm__ seems to be the way in ICC and Sun Studio
[15:39] mikko	asm or __asm__ in gcc
[15:39] Steve-o	meh, as long as there is a workaround, useful to note it in patch though
[15:40] Steve-o	from the link you had yesterday there seems to be three forms, __asm, __asm__, and asm
[15:40] mikko	yeah
[15:40] mikko	interesting enough i can't get ICC to support 'asm'
[15:41] mikko	and sun studio still complains about:
[15:41] mikko	"../foreign/openpgm/libpgm-5.0.91~dfsg/openpgm/pgm/include/pgm/atomic.h", line 46: warning: "__asm__" is an extension of ANSI C
[15:41] mikko	which i guess is fair
[15:41] Steve-o	that's probably why I'm checking for __GNUC__
[15:42] Steve-o	Intel don't provide any custom intrinsics so they're not really helping
[15:43] mikko	"asm" keyword works in ICC unless -strict-ansi is used
[15:45] Steve-o	I'll try updating upstream with it, I've been looking for -pedantic equivalents
[15:45] Steve-o	thanks
[15:46] mikko	np
[17:09] CIA-20	zeromq2: 03Martin Sustrik 07maint * rffcb0ba 10/ (AUTHORS configure.in src/zmq.cpp):
[17:09] CIA-20	zeromq2: Couple of patches for AIX build
[17:09] CIA-20	zeromq2: - RAND_bytes function resides in crypto library
[17:09] CIA-20	zeromq2: - pollfd on AIX used 'reqevents' instead of events and 'retnevents'
[17:09] CIA-20	zeromq2: instead of 'revents'
[17:09] CIA-20	zeromq2: Signed-off-by: Martin Sustrik <sustrik@250bpm.com> - http://bit.ly/bTf46m
[17:22] CIA-20	zeromq2: 03Martin Sustrik 07master * rffcb0ba 10/ (AUTHORS configure.in src/zmq.cpp):
[17:22] CIA-20	zeromq2: Couple of patches for AIX build
[17:22] CIA-20	zeromq2: - RAND_bytes function resides in crypto library
[17:22] CIA-20	zeromq2: - pollfd on AIX used 'reqevents' instead of events and 'retnevents'
[17:22] CIA-20	zeromq2: instead of 'revents'
[17:22] CIA-20	zeromq2: Signed-off-by: Martin Sustrik <sustrik@250bpm.com> - http://bit.ly/bTf46m
[17:22] CIA-20	zeromq2: 03Martin Sustrik 07master * rf77c8ca 10/ (AUTHORS configure.in src/zmq.cpp):
[17:22] CIA-20	zeromq2: Merge branch 'maint'
[17:22] CIA-20	zeromq2: * maint:
[17:22] CIA-20	zeromq2: Couple of patches for AIX build - http://bit.ly/d6kEuw
[17:53] Guthur	Is publisher side filtering being looked at currently? http://www.zeromq.org/topics:new-topics
[17:54] Guthur	I am actually specifically interested in the scenario mentioned in the white paper, ie. serving up Forex data
[18:08] mikko	Guthur: it's being discussed
[18:08] mikko	but it's a complicated matter
[18:09] Guthur	mikko, Is there any consensus one what the solution might be?
[18:29] mikko	Guthur: not that i know of
[18:31] Guthur	mikko: ok, cheers
[18:31] Guthur	I'll probably try to engineer some device for my own needs
[18:38] mikko	the problematic thing is forwarding the subscriptions
[18:38] mikko	and especially when there are intermediates
[23:33] Guthur	Has anyone else been checking out ZFL and in particular the ZPL ?
[23:34] Guthur	https://github.com/zeromq/zfl http://rfc.zeromq.org/spec:4