Re: [zeromq-dev] C++ assertion failed with Java client
On Thu, Feb 9, 2012 at 12:55 AM, Frittum Johannes johannes.frit...@austrocontrol.at wrote: But don't forget to automatically unit-test on every check in. Maybe some kind of continuous delivery pipeline could be setup for ZMQ... Maybe talk to Mikko about helping out with http://build.zero.mq/ and the rather significant number of environments he already has? Ian ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Tue, Feb 7, 2012 at 9:04 AM, AJ Lewis aj.le...@quantum.com wrote: I think this makes sense too. Check in early, check in often. Precisely. It is about lowering the latency between change and validation. Thanks for the explanation - this makes much more sense to me now. Great! -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
Hello Pieter! -Ursprüngliche Nachricht- Von: zeromq-dev-boun...@lists.zeromq.org [mailto:zeromq-dev- boun...@lists.zeromq.org] Im Auftrag von Pieter Hintjens Gesendet: Mittwoch, 8. Februar 2012 21:31 An: AJ Lewis Cc: ZeroMQ development list Betreff: Re: [zeromq-dev] C++ assertion failed with Java client On Tue, Feb 7, 2012 at 9:04 AM, AJ Lewis aj.le...@quantum.com wrote: I think this makes sense too. Check in early, check in often. Precisely. It is about lowering the latency between change and validation. But don't forget to automatically unit-test on every check in. Maybe some kind of continuous delivery pipeline could be setup for ZMQ... Therefore automated tests (unit/component, functional, non-functional, performance) would be needed. Maybe I look at it if I have more time to spare - At least I could try to set up the pipeline to poll the repo for changes, build automatically from that and report about its outcome a few minutes later online. Then we can add tests gradually for every function that is added/changed. That way the test base can grow. We get automatic health feedback from the system. If there is interest in that I can have a look. Regards Johannes Frittum ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On 09/02/2012, at 11:55 AM, Frittum Johannes wrote: Precisely. It is about lowering the latency between change and validation. But don't forget to automatically unit-test on every check in. Not enough. 0MQ isn't really amenable to unit testing. You need to actually create a network and check it performs as expected, i.e. a small scale integration test. Some of the existing tests do that using inproc, but that's suspicious because there's a lack of asynchronicity. Maybe some kind of continuous delivery pipeline could be setup for ZMQ... Therefore automated tests (unit/component, functional, non-functional, performance) would be needed. Absolutely. I have a process manager working now, that can start up and kill sets of processes running Guide examples. It's not ready for the big time yet but at least it isn't segfaulting now :) Maybe I look at it if I have more time to spare - At least I could try to set up the pipeline to poll the repo for changes, build automatically from that and report about its outcome a few minutes later online. Then we can add tests gradually for every function that is added/changed. That way the test base can grow. We get automatic health feedback from the system Yes, but it isn't functions that need testing, as configurations. The different socket types all use the same factory function. We need to check all the combinations, including some that are not supposed to work, and with multiple fanin/fanout etc. The best set of such tests already in existence is the examples in the Guide. Plus some tests using Python binding. If there is interest in that I can have a look. Absolutely. Just compiling the sources on different platforms would be a good start! Including all the guide examples. -- john skaller skal...@users.sourceforge.net ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Mon, Feb 06, 2012 at 05:08:22PM -0600, Pieter Hintjens wrote: On Mon, Feb 6, 2012 at 5:15 AM, Staffan Gimåker staf...@spotify.com wrote: We want to avoid relying on features that will never make it upstream as much as possible, so a work flow as outlined below makes more sense to me personally. * Propose a change upstream, either as an idea or a patch. * Hopefully get it reviewed and accepted. * Start using it internally, maintain it until it's available in an upstream release. If there was a staging repo where things got discussed and reviewed first, then accepted, and eventually merged to master, with any changes in it having a higher chance of survival, it's a work flow I'd consider. Indeed. This makes much sense. I've previously argued for using multiple repos for such separation but consensus was to use branches in one repo. Thus, the master branch is a staging area, and we then merge surviving (tested, proven) changes onto version branches. Ok, this is what I was missing. The main problem with relying on a review process is that, by experience, it rarely happens. We've proof of that over the last years as Martin Sustrik has diligently sent patches to this list, yet they are rarely reviewed. At the same time, downstreaming such trusted patches to 2.1 stable has on more than one occasion created broken releases. And the notion that some team has the right to accept or reject patches is bogus in an open source community. Who elects these group? Why are they special? What if they never actually use 0MQ themselves, how then do they judge the economics of a change? In fact the only people who can judge the pros and cons of a feature are real users. And they can't do this by review, they have to be able to use the code. My conclusion, from observing our work over years, is that only real use can validate patches, and this will take time, often many iterations as patches zoom in on the right solution. One cannot demand every contributor to immediately produce perfect solutions. It creates an insurmountable barrier. Thus, the goal of getting changes into use rapidly, via a this is experimental area. And the least surprising place is libzmq master. I think this makes sense too. Check in early, check in often. I'm writing a detailed analysis and explanation of the history of our current processes, which should allow an empirical approach to our work. Opinions don't have much value, they are by definition biased. We need quantitative measures that can be tracked over time. This is what I'd like to capture. Great! Looking forward to reading it. As for feature creep, we have the tools to manage that. They are the documented APIs and protocols. These are contracts that cannot be broken. They may be extended but anything that people do not use can be removed (and is, over time). Yeah - it seems like we definitely need some more tests to verify these are maintained. I guess as long as the binding authors are using the master branch (at least occasionally), there should be early warnings if things are broken. Thanks for the explanation - this makes much more sense to me now. -- AJ Lewis Software Engineer Quantum Corporation Mobile: 612 860-8068 Work:651 688-4346 YahooIM: vortechs2000 AIM: v0r73chz MSN: vortechs2...@yahoo.com email: aj.le...@quantum.com -- The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Sun, 2012-02-05 at 21:52 +0100, Pieter Hintjens wrote: On Sun, Feb 5, 2012 at 7:28 PM, Staffan Gimåker staf...@spotify.com wrote: I'd probably be more interested in contributing patches to such a repo than to what the zmq master is becoming. Would you explain the logic of that? The reason for pushing changes rapidly to libzmq master is to expose them to critique sooner, rather than later. This is where all automatic testing has its focus. I may have been a little rash in writing that reply, let me elaborate. But first, let me point out that I haven't been around here for very long, so I'm not intimately familiar with what lead up to the new governance model, nor have I had time to read all the e-mails going back and forth about it recently. I personally prefer any changes I (personally or as part of part of my work) make are reviewed first, and then accepted. Why? Because once they're reviewed and accepted they will probably stay accepted. In the model where things are merged immediately but might end up being reverted at much later date, we risk ending up in a situation where we have started depending on a feature that is later deemed unacceptable, which sort of puts us in the awkward spot of having to maintain our own changes forever. We want to avoid relying on features that will never make it upstream as much as possible, so a work flow as outlined below makes more sense to me personally. * Propose a change upstream, either as an idea or a patch. * Hopefully get it reviewed and accepted. * Start using it internally, maintain it until it's available in an upstream release. If there was a staging repo where things got discussed and reviewed first, then accepted, and eventually merged to master, with any changes in it having a higher chance of survival, it's a work flow I'd consider. I also have some concerns about quality and feature creep, although it's too early to tell if those concerns are valid or not. /S ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
Is or will this repo be publicly available anywhere? I'd probably be more interested in contributing patches to such a repo than to what the zmq master is becoming. /S On Sat, Feb 4, 2012 at 10:42 AM, Martin Sustrik sust...@250bpm.com wrote: On 03/02/12 18:37, AJ Lewis wrote: On Fri, Feb 03, 2012 at 05:16:06PM +, Christian Martinez wrote: First, I have to make a disclaimer that everything I'm about to say is my opinion only and does not reflect any official MSFT position. Heh - I guess I should put that disclaimer on my posts too - this is my opinion and doesn't reflect any official QTM position. Personally I love the give and take and don't feel threatened or upset by any of the shenanigans. I find them a natural part of the OSS process. Before I joined the monolith I used to work exclusively in the OSS world using things like ACE/TAO, MICO, every Java framework imaginable etc... There was never a shortage of interesting discussions/rants. What I've observed is that every one of the projects that were successful had a benevolent dictator and a few hard core contributors. As long as that basic infrastructure is there and passion remains then I feel comfortable telling as many folks as possible to check out 0MQ. We've embraced Node and Hadoop very publicly as a company and work deeply with those projects. I'd love it if someday we can do that with 0MQ as well. Definitely - just concerned that this model continues. Some of the talk about taking all patches blindly and waiting for other contributers to revert them makes me nervous. Are the original maintainers still going to consider themselves contributors, or are they expecting other community members to pick that up? Is there a core vision? I'm not sure who the benevolent dictator is in this project ATM, which may just mean I haven't been paying enough attention. I'm definitely more comfortable with the gatekeeper model that the linux kernel employs - where there are core maintainers that vet patches before they're committed to the main repo. I don't want to reopen that discussion - I know there's concerns about that model for historical reasons. I just need to watch what happens and get my head wrapped around it. To keep both of you calm: I am going to keep my own fork of the repo in the old rigorous and elitist way. I will commit/pull patches only after careful code review, track the code origin, reject anonymous patches, I will take care of fixing stability problems, focus on performance and versatility, push forward the vision of large-scale flexible topologies and ultimately push the whole thing towards inclusion into the OS and towards IETF standardisation. In other words, I'll continue to do what I've been doing since 2007. In short, there's nothing to fear. If this social experiment fails, there still will be a back-up option. Martin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Sun, Feb 5, 2012 at 7:28 PM, Staffan Gimåker staf...@spotify.com wrote: I'd probably be more interested in contributing patches to such a repo than to what the zmq master is becoming. Would you explain the logic of that? The reason for pushing changes rapidly to libzmq master is to expose them to critique sooner, rather than later. This is where all automatic testing has its focus. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On 03/02/12 18:37, AJ Lewis wrote: On Fri, Feb 03, 2012 at 05:16:06PM +, Christian Martinez wrote: First, I have to make a disclaimer that everything I'm about to say is my opinion only and does not reflect any official MSFT position. Heh - I guess I should put that disclaimer on my posts too - this is my opinion and doesn't reflect any official QTM position. Personally I love the give and take and don't feel threatened or upset by any of the shenanigans. I find them a natural part of the OSS process. Before I joined the monolith I used to work exclusively in the OSS world using things like ACE/TAO, MICO, every Java framework imaginable etc... There was never a shortage of interesting discussions/rants. What I've observed is that every one of the projects that were successful had a benevolent dictator and a few hard core contributors. As long as that basic infrastructure is there and passion remains then I feel comfortable telling as many folks as possible to check out 0MQ. We've embraced Node and Hadoop very publicly as a company and work deeply with those projects. I'd love it if someday we can do that with 0MQ as well. Definitely - just concerned that this model continues. Some of the talk about taking all patches blindly and waiting for other contributers to revert them makes me nervous. Are the original maintainers still going to consider themselves contributors, or are they expecting other community members to pick that up? Is there a core vision? I'm not sure who the benevolent dictator is in this project ATM, which may just mean I haven't been paying enough attention. I'm definitely more comfortable with the gatekeeper model that the linux kernel employs - where there are core maintainers that vet patches before they're committed to the main repo. I don't want to reopen that discussion - I know there's concerns about that model for historical reasons. I just need to watch what happens and get my head wrapped around it. To keep both of you calm: I am going to keep my own fork of the repo in the old rigorous and elitist way. I will commit/pull patches only after careful code review, track the code origin, reject anonymous patches, I will take care of fixing stability problems, focus on performance and versatility, push forward the vision of large-scale flexible topologies and ultimately push the whole thing towards inclusion into the OS and towards IETF standardisation. In other words, I'll continue to do what I've been doing since 2007. In short, there's nothing to fear. If this social experiment fails, there still will be a back-up option. Martin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Sat, Feb 4, 2012 at 02:43, Martin Lucina mar...@lucina.net wrote: So, to set things straight, as I was told yesterday in no uncertain terms: 1. Pieter Hintjens claims this community as *his* [2] 2. Martin Sustrik has resigned as the benevolent dictator [3] To borrow John Skaller's term from another thread, Pieter was the meta-dictator all along, and I didn't realise that. My bad. It's been clear to me that this is not a normal OSS community the way I know them, but thanks for laying things out. I'm kind of wondering about the private email conversations you, PH and MS had. Would it be possible to publish some of those conversations on this list? It feels like we got to see part of the results, but not the cause or origin or what happened behind the scenes. IMO, private email conversations on topics like this are very bad for the community, because there's no level playing field allowing everyone to participate equally. Cheers, Dirkjan ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Sat, Feb 4, 2012 at 12:24 AM, john skaller skal...@users.sourceforge.net wrote: So? It would also mean I can run the tests, on practically any machine, since Python is nice and portable (compared to C). Using PyZMQ as part of the libzmq make check process violates layering in quite a big way. At the same time John is right to suggest we're underusing PyZMQ in this capacity. It's clearly far cheaper to write test cases in Python than in C or C++. So the problem is that we need to run more tests on libzmq, more often, and we have excellent work that can do this but we're not using it fully. I can think of a few solutions: * Run the PyZMQ test scripts as part of the regular Jenkins build process * Carve off these test scripts as a more formal 0MQ test package that can be extended. * Start to create larger packages (libzmq + PyZMQ + CZMQ + jzmq + etc.) that can be tested together. Etc. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Sat, Feb 4, 2012 at 3:09 AM, Martin Lucina mar...@lucina.net wrote: Agreed, delivering quality is hard and costly. The new process appears to be an experiment in eliminating that cost. Certainly, in eliminating friction, which is unnecessary cost imposed by force. Please note that you maintained the 2.1 stable releases using a completely different process than that which is now being applied to master. Further, under that process, you only had to deal with a small amount of fixes to existing bugs in the code base. You did not have to deal with new code or contributions. We took 2.1 through a full year, from unstable to stable, with 96 itemized changes and 13 releases over that time. The older history often just says Many bugs were fixed because the process was so opaque at the time. IMO in the days of Martin Sustrik's lead, there was no unstable release, or at least not in the sense that we have now, since master was carefully vetted and maintained. Sure, there were other problems with what went on master, but code quality was not one of them. There were other *severe* problems. If you like I will remind you of them. But that is boring. Let's take another approach. Mato, I've seen this story happen often. You and Martin are really not the first case. What happens is that a small elite group swallow their own propaganda and believe they are better than everyone else. They write code that they barely, if ever use. They create complex processes that no-one else can take part in. They create friction left and right. In their minds, and arguments, this is always about quality. it is always about quality. Underlying their arguments is a constant tone of superiority. As people question them, they band together and insist they have the moral authority. But subconsciously, and we see this in the way you resort to emotional appeals and personal attacks, it is about *control* and insecurity. You're afraid that if a dozen other people can do your job effortlessly, you are somehow redundant. You always distrust people you can't control. It's cute but not original. You mentioned Wikipedia and it's exactly the same argument, made by small elites with complex, opaque processes, against the unwashed masses who will steal their jobs. The key to open source however, and the success of a community, is that you don't need to trust anyone except to be themselves. Everyone, even the insecure distrustful elites have their place. And over time, it's a happy and profitable place because -- and here's the nub -- no-one likes to be in control of a dying project. It is far better to be one of many, in a successful project, than the moral owner of a perfect, high-quality, irrelevant piece of cake. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Sat, Feb 4, 2012 at 11:42 AM, Dirkjan Ochtman dirk...@ochtman.nl wrote: I'm kind of wondering about the private email conversations you, PH and MS had. Would it be possible to publish some of those conversations on this list? I'm not OK with that. Private emails are not for public display, and publishing them would be a breach of confidence, and copyright. But open discussion, sure. This is an important matter and affects us all, and my intention is to make sure everyone's voice is heard and consensus opinion is implemented. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
p...@imatix.com said: On Sat, Feb 4, 2012 at 11:42 AM, Dirkjan Ochtman dirk...@ochtman.nl wrote: I'm kind of wondering about the private email conversations you, PH and MS had. Would it be possible to publish some of those conversations on this list? I'm not OK with that. Private emails are not for public display, and publishing them would be a breach of confidence, and copyright. But open discussion, sure. This is an important matter and affects us all, and my intention is to make sure everyone's voice is heard and consensus opinion is implemented. I have reviewed the relevant email threads in question, and it is my opinion that there is nothing of commercial importance in them. On the contrary, they do concern the ZeroMQ community. I would like to go on the record as stating: The threads in question are the full conversations defined by the following root messages: Date: Sun, 18 Dec 2011 11:35:32 -0600 From: Pieter Hintjens p...@imatix.com To: Martin Lucina mar...@lucina.net, Martin Sustrik sust...@250bpm.com Subject: 3.1 release Message-ID: cadl5_sid35nnfgeikyylqoamsgnc4xnzzr3duyddv7kk237...@mail.gmail.com (sfid-20111218_183555_619641_B879003B) Date: Tue, 20 Dec 2011 09:16:54 +0900 From: Martin Lucina mar...@lucina.net To: Pieter Hintjens p...@imatix.com Cc: sust...@250bpm.com Subject: 3.1 releases, Distributions Wiki page Message-Id: 20111220091654.05261dc03816046900f83...@lucina.net If, and only if, both Pieter Hintjens and Martin Sustrik give their consent to making these conversations public, in their entire and unredacted form, then I also give my consent to making these conversations public, in their entire and unredacted form. -mato signature.asc Description: Digital signature ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
dirk...@ochtman.nl said: It feels like we got to see part of the results, but not the cause or origin or what happened behind the scenes. IMO, private email conversations on topics like this are very bad for the community, because there's no level playing field allowing everyone to participate equally. You're right, and Martin Sustrik and myself have also been at fault on this during the time we were maintaining ZeroMQ. I don't have any excuse for that, but there never was any *intent* to keep anything concerning the community private. Also, a lot of discussion between Martin Sustrik and myself got done in person, simply because we live and work in the same city (Bratislava, Slovakia). If I was in that position again, I would make an effort to take minutes of those discussions; although sometimes they might suffer from being drenched in beer :-) Cheers, -mato ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
p...@imatix.com said: So the problem is that we need to run more tests on libzmq, more often, and we have excellent work that can do this but we're not using it fully. I can think of a few solutions: * Run the PyZMQ test scripts as part of the regular Jenkins build process +1, and there is also the rspec stuff in the ruby-ffi binding. * Carve off these test scripts as a more formal 0MQ test package that can be extended. +1 And: * A good C++ hacker could extend and formalise the existing tests which are already part of libzmq. -mato ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
Sure, I have no objections to making the emails public. Martin On 04/02/12 13:38, Martin Lucina wrote: p...@imatix.com said: On Sat, Feb 4, 2012 at 11:42 AM, Dirkjan Ochtmandirk...@ochtman.nl wrote: I'm kind of wondering about the private email conversations you, PH and MS had. Would it be possible to publish some of those conversations on this list? I'm not OK with that. Private emails are not for public display, and publishing them would be a breach of confidence, and copyright. But open discussion, sure. This is an important matter and affects us all, and my intention is to make sure everyone's voice is heard and consensus opinion is implemented. I have reviewed the relevant email threads in question, and it is my opinion that there is nothing of commercial importance in them. On the contrary, they do concern the ZeroMQ community. I would like to go on the record as stating: The threads in question are the full conversations defined by the following root messages: Date: Sun, 18 Dec 2011 11:35:32 -0600 From: Pieter Hintjensp...@imatix.com To: Martin Lucinamar...@lucina.net, Martin Sustriksust...@250bpm.com Subject: 3.1 release Message-ID:cadl5_sid35nnfgeikyylqoamsgnc4xnzzr3duyddv7kk237...@mail.gmail.com (sfid-20111218_183555_619641_B879003B) Date: Tue, 20 Dec 2011 09:16:54 +0900 From: Martin Lucinamar...@lucina.net To: Pieter Hintjensp...@imatix.com Cc: sust...@250bpm.com Subject: 3.1 releases, Distributions Wiki page Message-Id:20111220091654.05261dc03816046900f83...@lucina.net If, and only if, both Pieter Hintjens and Martin Sustrik give their consent to making these conversations public, in their entire and unredacted form, then I also give my consent to making these conversations public, in their entire and unredacted form. -mato ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Sat, Feb 4, 2012 at 2:03 PM, Martin Sustrik sust...@250bpm.com wrote: Sure, I have no objections to making the emails public. No objections either. I think we've done a very good job in the last couple of years in turning the private agreements into public contracts. Everyone involved in this project has a right to know what agreements are made, on what basis. Level playing field, indeed. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
Pieter, Martin, Ok, please confirm: p...@imatix.com said: On Sat, Feb 4, 2012 at 2:03 PM, Martin Sustrik sust...@250bpm.com wrote: Sure, I have no objections to making the emails public. No objections either. I think we've done a very good job in the last couple of years in turning the private agreements into public contracts. Everyone involved in this project has a right to know what agreements are made, on what basis. Level playing field, indeed. Do you trust me to take the complete text of these emails and, for the avoidance of doubt, for each each email include the following headers: - From: - To: - Cc: - Subject: - In-Reply-To: - Message-Id: and send the full, unredacted, text of these emails to this mailing list? -mato ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Sat, Feb 4, 2012 at 2:24 PM, Martin Lucina mar...@lucina.net wrote: Pieter, Martin, Do you trust me to take the complete text of these emails and, for the avoidance of doubt, for each each email include the following headers: Well, I'm at FOSDEM and don't have time to review these emails. Tomorrow, travelling the whole day, and this continues until end of next week. Furthermore this entire thread is wearisome. So in retrospect, and thanks for asking twice, no thank you. I did not write those emails (whatever they are) with the intention of publication. My recommendation is to focus on where we are today, and how to improve things, based on concrete evidence and scientific trial and error. Concretely, if anyone has an issue with any aspect of any contract published on the wiki, raise the issue with material evidence. We will discuss that, in open, if the problem is real, we will evaluate solutions and then apply them. I'm retiring from this thread now and will by necessity ignore any further discussion that isn't forward-focused and constructive. -Pieter Ps. for anyone who is at FOSDEM, I do have a bunch of 0MQ t-shirts to give out, M and L. I'll also bring some to Portland. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
p...@imatix.com said: On Sat, Feb 4, 2012 at 2:24 PM, Martin Lucina mar...@lucina.net wrote: Pieter, Martin, Do you trust me to take the complete text of these emails and, for the avoidance of doubt, for each each email include the following headers: Well, I'm at FOSDEM and don't have time to review these emails. Tomorrow, travelling the whole day, and this continues until end of next week. Furthermore this entire thread is wearisome. So in retrospect, and thanks for asking twice, no thank you. I did not write those emails (whatever they are) with the intention of publication. Right, so I got a no, then a yes, and then a no. I will take that to mean no. If anyone wishes to pursue this further, feel free. My word on this matter stands. -mato ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Sat, Feb 4, 2012 at 10:42 AM, Martin Sustrik sust...@250bpm.com wrote: I am going to keep my own fork of the repo in the old rigorous and elitist way. I will commit/pull patches only after careful code review, track the code origin, reject anonymous patches, I will take care of fixing stability problems, focus on performance and versatility, push forward the vision of large-scale flexible topologies and ultimately push the whole thing towards inclusion into the OS and towards IETF standardisation. In other words, I'll continue to do what I've been doing since 2007. :-) This is very good to hear. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Sat, Feb 4, 2012 at 3:04 PM, Martin Lucina mar...@lucina.net wrote: I will take that to mean no. If anyone wishes to pursue this further, feel free. My word on this matter stands. Indeed, that was a no. Thanks. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On 04/02/12 14:24, Martin Lucina wrote: Do you trust me to take the complete text of these emails and, for the avoidance of doubt, for each each email include the following headers: Sure. Np. Martin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On 03/02/2012, at 4:34 PM, Chuck Remes wrote: On Feb 2, 2012, at 11:21 PM, john skaller wrote: On 03/02/2012, at 2:32 PM, Chuck Remes wrote: I can't imagine how it would be done cleanly. I haven't thought about it as deeply as you, but in my experience this will be very difficult if not impossible to achieve. I welcome being proven wrong. :) Can you explain why simply setting a mutex at the start of every C API call, and releasing it at the end, would not work? the mutex object would live in the socket. I don't understand all the constraints of your Felix language, so anything I guess at would likely be wrong. Er, I'm confused. This has nothing to do with Felix. I'm talking about the Zero MQ C API. -- john skaller skal...@users.sourceforge.net ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Fri, Feb 3, 2012 at 6:34 AM, Chuck Remes cremes.devl...@mac.com wrote: Again, I have no opinion. I'll allow others to voice theirs. I'm always happy to collect and voice opinions. First, we'd enjoy a lot less mention of Felix here, it feels like zeromq-dev has become the target of a Felix astroturfing campaign. Second, John, though your enthusiasm is welcome in its general addition of energy to the list, it is doubtless irritating to people who have spent the last years carefully optimizing and tuning this library. My strong advice is to stop suggesting improvements as though they were obvious. Read my blog on Complexity Oriented Design if you want to understand why your proposal to invent fifteen (or was it 35) new semantics for message is not helpful. Third, and again from the same blog, the only sane way to work in a large and complex project like libzmq (or indeed in a tiny new project) is by single iterative steps where each step fixes a well-known, clearly argued problem in a *minimal* fashion. So, in summary, let's cut the philosophy and focus on targeted *minimal* patches to solve identified problems. I repeat the word *minimal* for emphasis. If you are spending fifteen emails arguing a design, it isn't minimal. Cheers -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
p...@imatix.com said: So, in summary, let's cut the philosophy and focus on targeted *minimal* patches to solve identified problems. +1, although minimal is a matter of opinion. Pieter, with all due respect, it's a shame that this community is turning into one driven by personal ideology rather than a meritocracy based on quality *technical* contributions. That was not what I signed up for when I started contributing to this project. Maybe you could also tone down the ideology a couple of points? I repeat the word *minimal* for emphasis. If you are spending fifteen emails arguing a design, it isn't minimal. Such as your design of defaulting to ZMQ_SUBSCRIBE () for SUB sockets? -mato ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Fri, Feb 3, 2012 at 11:40 AM, Martin Lucina mar...@lucina.net wrote: I repeat the word *minimal* for emphasis. If you are spending fifteen emails arguing a design, it isn't minimal. Such as your design of defaulting to ZMQ_SUBSCRIBE () for SUB sockets? To be fair, that just changed in the binding conventions thread :) Ian ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Fri, Feb 3, 2012 at 12:40 PM, Martin Lucina mar...@lucina.net wrote: Pieter, with all due respect, it's a shame that this community is turning into one driven by personal ideology rather than a meritocracy based on quality *technical* contributions. That was not what I signed up for when I started contributing to this project. It's never clear to me when you are on-board and abandoning 0MQ. It's fair to assume this is one of your on board phases? Personal pokes aside, the goals of what you call ideology are quite simple and I don't think uncontroversial unless you're in the line of fire. libzmq has been throttled by elitist decision making, to a point where the broad voice of the community was ignored in favour of the personal opinion (now here is where you can use the term ideology accurately) of a very few people. Maybe you could also tone down the ideology a couple of points? Do you really want to get into this, Mato? There is very little I say or do that isn't the result of consultation with others. Such as your design of defaulting to ZMQ_SUBSCRIBE () for SUB sockets? That is an old design, discussed at the time, and one that I tried for pragmatic reasons. Since people don't like it, I've changed it. Anyone could have sent me a patch to CZMQ, I'd have accepted it without issue. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Feb 3, 2012, at 3:47 AM, john skaller wrote: On 03/02/2012, at 4:34 PM, Chuck Remes wrote: On Feb 2, 2012, at 11:21 PM, john skaller wrote: On 03/02/2012, at 2:32 PM, Chuck Remes wrote: I can't imagine how it would be done cleanly. I haven't thought about it as deeply as you, but in my experience this will be very difficult if not impossible to achieve. I welcome being proven wrong. :) Can you explain why simply setting a mutex at the start of every C API call, and releasing it at the end, would not work? the mutex object would live in the socket. I don't understand all the constraints of your Felix language, so anything I guess at would likely be wrong. Er, I'm confused. This has nothing to do with Felix. I'm talking about the Zero MQ C API. Then I'm confused too. I thought this discussion was in the context of Felix which, as you have noted a few times, uses thousands or millions of pthreads fibers/coroutines behind the scenes. A mutex works fine with a 0mq socket so adding one to the socket itself would also work. I just don't think it would perform well plus everyone would have to pay that price even if they didn't need it. Yuck. cr ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
Then I'm confused too. Great minds .. unthink alike? :) -- john skaller skal...@users.sourceforge.net ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Fri, Feb 03, 2012 at 12:40:03PM +0100, Martin Lucina wrote: p...@imatix.com said: So, in summary, let's cut the philosophy and focus on targeted *minimal* patches to solve identified problems. +1, although minimal is a matter of opinion. Pieter, with all due respect, it's a shame that this community is turning into one driven by personal ideology rather than a meritocracy based on quality *technical* contributions. That was not what I signed up for when I started contributing to this project. Maybe you could also tone down the ideology a couple of points? What you're not taking into account with your meritocracy idea is all the quiet users of this library that *aren't* contributing patches, but rely on the functionality of the library for their work. If we're going to tip zmq on it's head because a couple very vocal contributors decide they don't like the way things have been working, it makes me very concerned about continuing to use this project. Is this something that I can rely on, or will it turn into an open source project that bounces all over the place depending on the whims of the contributor of the week? I want people to contribute - I'm very happy that my fixes for various platforms have been accepted without issue - but I am concerned that project could be hijacked by someone that has a very specific use case for it and doesn't understand the history and philosophy of the proejct and what its current users are doing with it. /me goes back to lurking... -- AJ Lewis Software Engineer Quantum Corporation Work:651 688-4346 -- The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Fri, Feb 03, 2012 at 05:16:06PM +, Christian Martinez wrote: First, I have to make a disclaimer that everything I'm about to say is my opinion only and does not reflect any official MSFT position. Heh - I guess I should put that disclaimer on my posts too - this is my opinion and doesn't reflect any official QTM position. Personally I love the give and take and don't feel threatened or upset by any of the shenanigans. I find them a natural part of the OSS process. Before I joined the monolith I used to work exclusively in the OSS world using things like ACE/TAO, MICO, every Java framework imaginable etc... There was never a shortage of interesting discussions/rants. What I've observed is that every one of the projects that were successful had a benevolent dictator and a few hard core contributors. As long as that basic infrastructure is there and passion remains then I feel comfortable telling as many folks as possible to check out 0MQ. We've embraced Node and Hadoop very publicly as a company and work deeply with those projects. I'd love it if someday we can do that with 0MQ as well. Definitely - just concerned that this model continues. Some of the talk about taking all patches blindly and waiting for other contributers to revert them makes me nervous. Are the original maintainers still going to consider themselves contributors, or are they expecting other community members to pick that up? Is there a core vision? I'm not sure who the benevolent dictator is in this project ATM, which may just mean I haven't been paying enough attention. I'm definitely more comfortable with the gatekeeper model that the linux kernel employs - where there are core maintainers that vet patches before they're committed to the main repo. I don't want to reopen that discussion - I know there's concerns about that model for historical reasons. I just need to watch what happens and get my head wrapped around it. If you're concerned with stability take a branch/build, stick to that and maybe pick up a support contract especially if you're restricted to binary only... Yep, I can do that. I can fork the project if it goes in a direction that doesn't continue to work for what I'm doing with it too if I have too, but I *really* don't want to do that. There's lots of really smart people that have worked to get zmq to where it is today - I just hope they continue to steer it a bit and don't give up the rudder completely. This is an amazing project! I'm excited to see where it's going, and will contribute where I can. I'll do my best to keep up with the changes and voice my opinion/contribute patches where I'm able, but we're currently using 2.1.X, so it's hard to be very active on the libzmq branch. Well that's enough pontificating I'll go back to hacking the broken Node binding now (It breaks under Node's move to libuv ...nothing really to do with 0MQ which I'm barred from hacking directly :( ) :D -Original Message- From: zeromq-dev-boun...@lists.zeromq.org [mailto:zeromq-dev-boun...@lists.zeromq.org] On Behalf Of AJ Lewis Sent: Friday, February 03, 2012 9:35 AM To: ZeroMQ development list Subject: Re: [zeromq-dev] C++ assertion failed with Java client On Fri, Feb 03, 2012 at 12:40:03PM +0100, Martin Lucina wrote: p...@imatix.com said: So, in summary, let's cut the philosophy and focus on targeted *minimal* patches to solve identified problems. +1, although minimal is a matter of opinion. Pieter, with all due respect, it's a shame that this community is turning into one driven by personal ideology rather than a meritocracy based on quality *technical* contributions. That was not what I signed up for when I started contributing to this project. Maybe you could also tone down the ideology a couple of points? What you're not taking into account with your meritocracy idea is all the quiet users of this library that *aren't* contributing patches, but rely on the functionality of the library for their work. If we're going to tip zmq on it's head because a couple very vocal contributors decide they don't like the way things have been working, it makes me very concerned about continuing to use this project. Is this something that I can rely on, or will it turn into an open source project that bounces all over the place depending on the whims of the contributor of the week? I want people to contribute - I'm very happy that my fixes for various platforms have been accepted without issue - but I am concerned that project could be hijacked by someone that has a very specific use case for it and doesn't understand the history and philosophy of the proejct and what its current users are doing with it. /me goes back to lurking... -- AJ Lewis Software Engineer Quantum Corporation Work:651 688-4346 -- The information contained
Re: [zeromq-dev] C++ assertion failed with Java client
On 04/02/2012, at 4:31 AM, Chuck Remes wrote: Your experience with OSS mirrors mine (benevolent dictator plus a few hard-core contributors). With 0mq we are trying to modify that a bit where there is no benevolent dictator and we want a lot more than just a few hard-core contributors. :) Oh, but don't forget the Peter Principle. The Benevolent Dictator just gets elevated up to Benevolent Meta-Dictator. -- john skaller skal...@users.sourceforge.net ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On 04/02/2012, at 4:37 AM, AJ Lewis wrote: Definitely - just concerned that this model continues. Some of the talk about taking all patches blindly and waiting for other contributers to revert them makes me nervous. The Benevolent Dictator has set strict standards: coding style, rules for process. Dictator doesn't want to be bogged down vetting patches. As one of my game playing friends said to me: I don't want to be a foot soldier, I want to be a General :) Have you heard of QA? I mean ISO Quality Control Standards. You probably know, these quality control measures involve: (a) a statement of commitment to quality (b) strict adherence to monitoring operations .. but have NOTHING to say about actual product quality. The idea is simply that there are ways to measure quality and they're applied, and there are ways to find out what caused a problem, no matter how it is discovered, and fix it. It's all about identification and tracking, as a tool for implementing the quality commitment. Here, Git does a lot of this work. Opening up the code base for patches should *increase* quality because it reduces the feedback time for contributions. Make a patch quicker .. and have people checking it out quicker too. IMHO the really big hole in he current setup is the lack of a substantial test base: regression tests, unit tests, integration tests, performance measurements. So I would stop feeling nervous about vetting of patches .. and start feeling nervous about the lack of test code :) -- john skaller skal...@users.sourceforge.net ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Sat, Feb 04, 2012 at 04:57:13AM +1100, john skaller wrote: On 04/02/2012, at 4:37 AM, AJ Lewis wrote: Definitely - just concerned that this model continues. Some of the talk about taking all patches blindly and waiting for other contributers to revert them makes me nervous. snip So I would stop feeling nervous about vetting of patches .. and start feeling nervous about the lack of test code :) Heh - that is true. The key here is that test code will catch when changes break what was previously working - whether that's a bug or a change in interface. If we has such tests, changes to the tests themselves should get greater scrutiny, especially if they're accompanied by library code changes, since there's more likely to be interface changes (or bugs being worked around!) in that case. I'm a big fan of the concept of Test Driven Design - having contracts that are enforced by the test subsystem goes a long way to keeping things sane. At least then you *know* that you're breaking an interface rather than finding out after the fact! Regards, -- AJ Lewis Software Engineer Quantum Corporation Work:651 688-4346 -- The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Fri, Feb 03, 2012 at 12:58:10PM -0600, Chuck Remes wrote: On Feb 3, 2012, at 12:24 PM, AJ Lewis wrote: On Sat, Feb 04, 2012 at 04:57:13AM +1100, john skaller wrote: On 04/02/2012, at 4:37 AM, AJ Lewis wrote: Definitely - just concerned that this model continues. Some of the talk about taking all patches blindly and waiting for other contributers to revert them makes me nervous. snip So I would stop feeling nervous about vetting of patches .. and start feeling nervous about the lack of test code :) Heh - that is true. The key here is that test code will catch when changes break what was previously working - whether that's a bug or a change in interface. If we has such tests, changes to the tests themselves should get greater scrutiny, especially if they're accompanied by library code changes, since there's more likely to be interface changes (or bugs being worked around!) in that case. I'm a big fan of the concept of Test Driven Design - having contracts that are enforced by the test subsystem goes a long way to keeping things sane. At least then you *know* that you're breaking an interface rather than finding out after the fact! The problem is trying to retrofit an existing codebase with tests. It is very difficult. I'd love to see a good C/C++ coder tackle it; I tried but it was beyond my capabilities. Oh, certainly! It is very difficult if it wasn't part of the design from the start. I've had this problem everywhere I've worked - there's always some code or product that doesn't have a good integrated test system. Unfortunately, I've not found a simple answer to getting that in place either. It seems to mostly require brute force. :( That said, it's definitely worth the time it takes to do it in the time saved in detecting issues after it's in place! IMO, it seems to me that a framework needs to be agreed upon (if it hasn't been already - is the automake test framework good enough?) then we need to start layering tests in that framework - especially around the external API to begin with. Regards, -- AJ Lewis Software Engineer Quantum Corporation Work:651 688-4346 -- The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Fri, Feb 3, 2012 at 6:57 PM, john skaller skal...@users.sourceforge.net wrote: So I would stop feeling nervous about vetting of patches .. and start feeling nervous about the lack of test code :) Actually there is test code, lots of it, written on top of the bindings. PyZMQ for instance has a huge test suite that has caught several major regressions. As regards the process, I'll explain once more, because this seems to be a subtle point: * In unstable code you want the maximum possible contribution range to ensure that real problems are solved accurately * In stable code you want the most brutal possible test policy, to ensure that existing applications are secured. My business, for 30 years, has been to deliver robust industrial-quality code that people can rely on 24/7. There is no way in heck anything calling itself ZeroMQ will be released as an *official* stable package by iMatix without satisfying extremely high levels of quality. The debate here is whether the old meritocracy can deliver that quality or not. The evidence suggests it can, but only with huge effort. However, over the last years I've been able to maintain several 2.x releases with minimal effort, and maintain high quality, by allowing _anyone_ to submit patches and at the same time apply a tough fix test process. If I can do it, anyone can. Hence, the role of maintainer as neutral bureaucrat, and contributors (all of us) as votes. And yes, a large part of this dictatorial move was to relieve Martin Sustrik of an enormous burden, to allow him more space to do what he does best, write amazing code that does amazing stuff, simply and elegantly and faster than anything ever before. Now, i see another FOUR pull requests have piled up in the last hours, so I'm going to process them. Cheers Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On 04/02/2012, at 7:30 AM, Pieter Hintjens wrote: On Fri, Feb 3, 2012 at 6:57 PM, john skaller skal...@users.sourceforge.net wrote: So I would stop feeling nervous about vetting of patches .. and start feeling nervous about the lack of test code :) Actually there is test code, lots of it, written on top of the bindings. PyZMQ for instance has a huge test suite that has caught several major regressions. Oh really? I didn't know that. Can someone point me at this code? Python tests would suit me well. Why not ship all that code with libzmq for testing? -- john skaller skal...@users.sourceforge.net ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Fri, Feb 3, 2012 at 14:39, john skaller skal...@users.sourceforge.netwrote: On 04/02/2012, at 7:30 AM, Pieter Hintjens wrote: On Fri, Feb 3, 2012 at 6:57 PM, john skaller skal...@users.sourceforge.net wrote: So I would stop feeling nervous about vetting of patches .. and start feeling nervous about the lack of test code :) Actually there is test code, lots of it, written on top of the bindings. PyZMQ for instance has a huge test suite that has caught several major regressions. Oh really? I didn't know that. Can someone point me at this code? Python tests would suit me well. PyZMQ tests are meant to test pyzmq itself, not libzmq. But there are ~100 tests, and regressions in libzmq have shown up a number of times as crashes or failures in pyzmq. The test suite is here: https://github.com/zeromq/pyzmq/tree/master/zmq/tests Why not ship all that code with libzmq for testing? That would mean shipping the entire Python binding with libzmq. -- john skaller skal...@users.sourceforge.net ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On 04/02/2012, at 10:02 AM, MinRK wrote: Why not ship all that code with libzmq for testing? That would mean shipping the entire Python binding with libzmq. So? It would also mean I can run the tests, on practically any machine, since Python is nice and portable (compared to C). But actually, I suppose I meant: the *source* version of libzmq (not a binary install). So I can just say make test have all the tests run before I try to push a patch. -- john skaller skal...@users.sourceforge.net ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Fri, Feb 3, 2012 at 15:24, john skaller skal...@users.sourceforge.netwrote: On 04/02/2012, at 10:02 AM, MinRK wrote: Why not ship all that code with libzmq for testing? That would mean shipping the entire Python binding with libzmq. So? It would also mean I can run the tests, on practically any machine, since Python is nice and portable (compared to C). You can still run them, whether they are in the same repo or not. I don't see a sufficient reason to merge two projects just because one has lots of tests. But actually, I suppose I meant: the *source* version of libzmq (not a binary install). So I can just say make test have all the tests run before I try to push a patch. Why not just run `nosetests -vvs zmq.tests`? This will run the pyzmq test suite if you have pyzmq installed, and you do not generally have to rebuild pyzmq when you make small changes to libzmq, because it's dynamically linked. I think the most important reason to not rely on the pyzmq test suite for libzmq is that it would recommend a different pattern for what I do when bugs in libzmq cause errors or failures. When I find a bug in libzmq, I typically add a Skip or workaround to the test (after notifying libzmq-dev or Jira about the bug), so that the suite continues to pass. The reason for this is that the goal of the pyzmq test suite is *not* to test libzmq, and failures in the suite should mean bugs in pyzmq. If testing libzmq were the goal, the tests would be quite different. *A* test suite of libzmq written largely in Python may still be a good idea, because it's a lot easier to write many small tests in Python, but it probably doesn't belong as the pyzmq test suite. -MinRK -- john skaller skal...@users.sourceforge.net ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
aj.le...@quantum.com said: What you're not taking into account with your meritocracy idea is all the quiet users of this library that *aren't* contributing patches, but rely on the functionality of the library for their work. To clarify what I meant by meritocracy: An Open Source project, with a benevolent dictator (or gatekeeper), and a community of contributors. The standard model, as employed by many successful Open Source projects out there. When I started contributing to ZeroMQ in late 2009 [1], I did so on the understanding that this project followed that model, and that the benevolent dictator was Martin Sustrik. It turns out those were false premises; and I only realise that now, *two years later*, after a long conversation with Pieter Hintjens yesterday. The crux of many of my arguments with Pieter comes from this single misunderstanding from two years ago; according to Pieter this was never the case, and it was only by his good grace that we (Martin and myself) were allowed to maintain ZeroMQ or parts thereof from late 2009 until mid-2011 in my case, and December 2011 in Martin Sustrik's case. So, to set things straight, as I was told yesterday in no uncertain terms: 1. Pieter Hintjens claims this community as *his* [2] 2. Martin Sustrik has resigned as the benevolent dictator [3] To borrow John Skaller's term from another thread, Pieter was the meta-dictator all along, and I didn't realise that. My bad. If we're going to tip zmq on it's head because a couple very vocal contributors decide they don't like the way things have been working, it makes me very concerned about continuing to use this project. What you are seeing now is Pieter implementing his vision for the community. Please note that this is not an attack against Pieter -- this is being done in consultation with the community, but ultimately rests on Pieter's power as meta-dictator. Is this something that I can rely on, or will it turn into an open source project that bounces all over the place depending on the whims of the contributor of the week? I want people to contribute - I'm very happy that my fixes for various platforms have been accepted without issue - but I am concerned that project could be hijacked by someone that has a very specific use case for it and doesn't understand the history and philosophy of the proejct and what its current users are doing with it. That depends on where the new process leads the community. I have argued consistently against the more controversial points, with little success -- my rhetoric is not up to meta-dictator standards :-) If you care about this, the only way [4] to achieve change today is to be vocal, and to criticise and argue those points of the process which you care about. Having known Pieter personally for more than 10 years now, and spent many many hours arguing with him, I wish you luck! TL;DR: One last point: In my humble but correct opinion: Under Martin Sustrik's lead, we had a mediocre community, and a great product. Under Pieter Hintjens' lead, we have a great community, but are rapidly progressing towards a mediocre product. Welcome to the Brave New World of software-engineering-as-a-wiki! -mato [1] At the time we published the LWN article with Martin Sustrik: http://lwn.net/Articles/370307/ [2] Stated by Pieter many times on this mailing list, if not in so few words. [3] Private e-mail thread between PH, MS and myself, December 2011. [4] The other option is a fork (in the formal sense, not the Github sense). This is an option of *last resort*, and is not something to be taken lightly. However, it does put you on a fair playing ground; build your own community and process, and ultimately users will follow the leader with their feet. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
cremes.devl...@mac.com said: Well that's enough pontificating I'll go back to hacking the broken Node binding now (It breaks under Node's move to libuv ...nothing really to do with 0MQ which I'm barred from hacking directly :( ) So sad. The library needs some serious love on the Windows platform (ipc transport, zmq_poll, etc) but most of the contributors are UNIX-only. Please do some lobbying if you can! Indeed! IOCP, please! Lots of the current performance and scalability problems on Windows come from the fact that we're using select(). IOCP is the obvious way to go there, but needs a hardcore hacker to map the IOCP concepts onto libzmq internals. -mato ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
p...@imatix.com said: The debate here is whether the old meritocracy can deliver that quality or not. The evidence suggests it can, but only with huge effort. However, over the last years I've been able to maintain several 2.x releases with minimal effort, and maintain high quality, by allowing _anyone_ to submit patches and at the same time apply a tough fix test process. Agreed, delivering quality is hard and costly. The new process appears to be an experiment in eliminating that cost. Please note that you maintained the 2.1 stable releases using a completely different process than that which is now being applied to master. Further, under that process, you only had to deal with a small amount of fixes to existing bugs in the code base. You did not have to deal with new code or contributions. IMO in the days of Martin Sustrik's lead, there was no unstable release, or at least not in the sense that we have now, since master was carefully vetted and maintained. Sure, there were other problems with what went on master, but code quality was not one of them. -mato ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Thu, Feb 2, 2012 at 6:42 AM, Kishore Kopalle kkopa...@gmail.com wrote: I am receiving the following errors when I try to work in a multi-threaded environment (10 threads) where ZeroMQ is used to send/receive messages You are using 0MQ sockets from multiple threads? That will crash. Please read the Guide wrt how to do multithreading in ZeroMQ. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On 02/02/2012, at 10:18 PM, Pieter Hintjens wrote: On Thu, Feb 2, 2012 at 6:42 AM, Kishore Kopalle kkopa...@gmail.com wrote: I am receiving the following errors when I try to work in a multi-threaded environment (10 threads) where ZeroMQ is used to send/receive messages You are using 0MQ sockets from multiple threads? That will crash. Q: is it technically feasible to make a thread-safe wrapper around 0MQ sockets? -- john skaller skal...@users.sourceforge.net ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
skal...@users.sourceforge.net said: On 02/02/2012, at 10:18 PM, Pieter Hintjens wrote: On Thu, Feb 2, 2012 at 6:42 AM, Kishore Kopalle kkopa...@gmail.com wrote: I am receiving the following errors when I try to work in a multi-threaded environment (10 threads) where ZeroMQ is used to send/receive messages You are using 0MQ sockets from multiple threads? That will crash. Q: is it technically feasible to make a thread-safe wrapper around 0MQ sockets? Sure, chuck a bunch of locks around socket-related calls? A mutex implies a full memory barrier, so things should work OK at least on cache-coherent architectures. Performance will take a nose-dive of course, but if that is not a concern, go for it ... -mato ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On 02/02/2012, at 10:36 PM, Martin Lucina wrote: Q: is it technically feasible to make a thread-safe wrapper around 0MQ sockets? Sure, chuck a bunch of locks around socket-related calls? A mutex implies a full memory barrier, so things should work OK at least on cache-coherent architectures. Performance will take a nose-dive of course, but if that is not a concern, go for it ... I would put these directly in the official ZMQ C API. The rationale is that ZMQ's own rationale is that you can program with ZMQ instead of using all those nasty locks, share memory barriers, and all the other things that make multi-threaded programming a nightmare. In Felix I have a garbage collector: flx_collector_t and a second collector flx_ts_collector_t which is a thread-safe wrapper around the first one: both are derived from flx_gc_t abstract class in the C++ code. The wrapping should be done in C++ and exported to C, not in C around the C API. IMHO. Which means it has to be part of the ZMQ C API standard. The reason is I think (a) the locking can be made somewhat conditional and (b) because of the particular structure of ZMQ other techniques which can avoid mutex or semaphores may be used. (c) it makes the Windows and Posix usage of ZMQ the same in an environment where 0MQ sockets are used in several threads, rather than forcing the client to use OS local locking techniques. It's not clear if the right way is to have a zmq_context, and a zmq_ts_context, so that if you make the latter all the socket objects spawned off it are thread safe. This is clearly simpler and avoids changes to the other functions, but it provides less control and therefore imposes an overhead. -- john skaller skal...@users.sourceforge.net ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Feb 2, 2012, at 6:03 AM, john skaller wrote: I would put these directly in the official ZMQ C API. The rationale is that ZMQ's own rationale is that you can program with ZMQ instead of using all those nasty locks, share memory barriers, and all the other things that make multi-threaded programming a nightmare. In Felix I have a garbage collector: flx_collector_t and a second collector flx_ts_collector_t which is a thread-safe wrapper around the first one: both are derived from flx_gc_t abstract class in the C++ code. The wrapping should be done in C++ and exported to C, not in C around the C API. IMHO. Which means it has to be part of the ZMQ C API standard. The reason is I think (a) the locking can be made somewhat conditional and (b) because of the particular structure of ZMQ other techniques which can avoid mutex or semaphores may be used. (c) it makes the Windows and Posix usage of ZMQ the same in an environment where 0MQ sockets are used in several threads, rather than forcing the client to use OS local locking techniques. It's not clear if the right way is to have a zmq_context, and a zmq_ts_context, so that if you make the latter all the socket objects spawned off it are thread safe. This is clearly simpler and avoids changes to the other functions, but it provides less control and therefore imposes an overhead. I think this suggestion is very misguided. I also infer from your suggestion that you haven't really grok'ed the essence of 0mq. There is a simple Rule for using 0mq with threads. That Rule is: *Only* use a socket from the thread that created it. If you follow that Rule, 0mq and threads get along swimmingly. There is no need for complicating the API or making the internals to the library more complex. I use 0mq in a highly multi-threaded application. I follow The Rule and have had *no problems* with scaling. When I need to communicate between threads, I use 0mq sockets to handle the message passing for me (via inproc transport). I have successfully used this technique to coordinate work between 48+ live threads and over 30k active sockets across a LAN in my cluster. I don't want libzmq made more complex and *slow* just because it takes a little extra effort and design to follow The Rule. For those *few* occasions where it is imperative that multiple threads share a single socket, a mutex may be used to protect it. This is *standard practice* for sharing any data structure amongst threads so it shouldn't be a surprise. I have used this technique in some small utility programs and it works well enough without any additional in-library support. Lastly, I think it's time to trot out an old blog post that Martin Sustrik wrote on this topic. http://www.zeromq.org/blog:multithreading-magic cr ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On 02/02/2012, at 10:36 PM, Martin Lucina wrote: skal...@users.sourceforge.net said: Q: is it technically feasible to make a thread-safe wrapper around 0MQ sockets? Sure, chuck a bunch of locks around socket-related calls? A mutex implies a full memory barrier, so things should work OK at least on cache-coherent architectures. Performance will take a nose-dive of course, but if that is not a concern, go for it ... BTW: are you so sure performance will suffer? The reason I ask is related to existing overheads: (a) malloc/free is used extensively in real applications, it is already thread-safe so it is using at least some combination of locks and TLS (b) the use of errno by 0MQ is a performance overhead already: errno is in TLS which has a nasty overhead. If you want to improve performance give up on, or at least provide a sane alternative to, errno. Fast barriers are provided on multi-cores, implemented directly in the hardware. There are also lock free synchronisation primitives on all modern CPUs. Are you sure Python users will care? I mean Python is 10,000 slower than C, and it already uses a global lock every few VM instructions. So does Ocaml bytecode interpreter. A couple of extra locks won't even be noticed. === Hmmm .. here's the problem: multi-part messages. This is done very badly. It was patched onto 0MQ. It should be supported by recv_array send_array not a flag and sequenced operations. That is already intrinsically unsafe in single threaded mode, but untenable in a multi-threaded mode. If we had these operations, locking could be automatic. The idea is simply to also add a new call: zmq_create_ts_context and then all sockets derived from this would have a flag set which causes locks to protect the operations. This will NOT protect the current multi-part messages so we have to add the new operations for that. The cost for maintaining the old semantics is: (a) a check on a flag for every function call (b) one machine word for a (pointer to) a mutex IMHO the check on the flag is fast enough to be ignored. The one machine word overhead may be more significant. There is another way to do this WITHOUT any memory overhead: use separate data structure in the context object to find the socket's mutex object: I'd use a JudyLArray myself, but a C++ map would do. The overhead is then a couple of words per context which is irrelevant. [The spawning of a new socket itself requires a mutex if you use a such a data structure since the modification of that data structure must also be thread-safe] BTW: if this were a C++ API instead of a C one the flag check would be un-necessary: you'd just use virtual functions to dispatch to the appropriate routine. And since the core is written in C++ anyhow this is another solution. The cost is then the cost of virtual dispatch, which is probably higher than a flag check ;( -- john skaller skal...@users.sourceforge.net ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On 03/02/2012, at 12:05 AM, Chuck Remes wrote: I think this suggestion is very misguided. I also infer from your suggestion that you haven't really grok'ed the essence of 0mq. There is a simple Rule for using 0mq with threads. That Rule is: *Only* use a socket from the thread that created it. If you follow that Rule, 0mq and threads get along swimmingly. Oh, I grok the rule just fine, but perhaps you don't perceive the impact on frameworks where the client doesn't have that kind of control .. or simply doesn't care .. Felix handles several *million* threads. (TCP) socket I/O is done the same way ZMQ does it: in a background thread. ZMQ sockets in Felix currently block the containing pthread, which is no good. To fix that the I/O will be lifted into a background thread. So it is *guaranteed* the I/O will happen in a different thread to the one that created the socket :) But still I doubt any extra locks are required at present since ALL the I/O is done in the background. OTOH if I do what 0MQ does -- and provide more than one background thread, I may need interlocking. It's likely applications such as a webserver will have a set of waiting fibres (one per connection or more), and they'll be farmed out to an arbitrary p-thread allocated from a pool. In that case, how can the client possibly obey the Rule since they have no control over which p-thread does the work? if you're stuck writing applications in C from the ground up you may well have the design control to obey the Rule but you can't assume people using advanced languages or frameworks, including stuff like Python, will have that kind of control. 0MQ isn't the only way to make multi-threaded programming safer. It needs to be able to fit in with other technologies. -- john skaller skal...@users.sourceforge.net ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Feb 2, 2012, at 8:23 AM, john skaller wrote: Oh, I grok the rule just fine, but perhaps you don't perceive the impact on frameworks where the client doesn't have that kind of control .. or simply doesn't care .. Felix handles several *million* threads. (TCP) socket I/O is done the same way ZMQ does it: in a background thread. ZMQ sockets in Felix currently block the containing pthread, which is no good. To fix that the I/O will be lifted into a background thread. So it is *guaranteed* the I/O will happen in a different thread to the one that created the socket :) But still I doubt any extra locks are required at present since ALL the I/O is done in the background. OTOH if I do what 0MQ does -- and provide more than one background thread, I may need interlocking. It's likely applications such as a webserver will have a set of waiting fibres (one per connection or more), and they'll be farmed out to an arbitrary p-thread allocated from a pool. In that case, how can the client possibly obey the Rule since they have no control over which p-thread does the work? if you're stuck writing applications in C from the ground up you may well have the design control to obey the Rule but you can't assume people using advanced languages or frameworks, including stuff like Python, will have that kind of control. 0MQ isn't the only way to make multi-threaded programming safer. It needs to be able to fit in with other technologies. John, I am glad you have joined the 0mq community. It thrives on new ideas, fresh blood and motivated programmers. You are all three. But (you knew there was a but coming, right?) you still don't grok it. When I first wrote the Ruby bindings, I used it as an exercise to learn the library. I translated a few of the examples, got them running and was pretty pleased with myself. Then I decided to write a real app using the bindings. At least 6 months later, it occurred to me that without that first real and non-trivial application, I didn't really know 0mq at all. I certainly was comfortable with the concepts and their usage, but trying to get the code to work in a useful manner was the acid test. As far as I can see, you haven't even finished your Felix bindings but you are participating in at least 3 threads on this list with very strong opinions on how to change libzmq. What's worse is that you could solve the issues you mention above without a single change to libzmq. As the author of your binding, you can choose to present any reasonable api to your users. That facade can perform all manner of locking (memory barriers) to make massively-multithreaded code safe and to shield your Felix users from the underlying complexity. Try to do this with the current constraints that libzmq places on you and see how far you get. At this time, we have bindings for every major language (C, Java, Ruby, Python, LISP, OCaml, Lua, Erlang) many of which have runtimes that have additional limitations when using C-based libraries like libzmq. If those myriad runtimes and languages can somehow support libzmq safely and efficiently *without changing* libzmq, then I think you can figure out how to do the same for Felix. Please, please finish your bindings and *write at least one real non-trivial application* before you form too many strong opinions about how libzmq should change. I hope you don't take my suggestion as being rude. I do not intend it that way. Also, don't abandon us. We need you and others like you, but we need you better informed. cr ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
Looks like Felix has processes/threads/fibers similar to Erlang processes. John, you could check erlzmq2 bingings to see how it is done there On Feb 2, 2012 3:45 PM, Chuck Remes cremes.devl...@mac.com wrote: On Feb 2, 2012, at 8:23 AM, john skaller wrote: Oh, I grok the rule just fine, but perhaps you don't perceive the impact on frameworks where the client doesn't have that kind of control .. or simply doesn't care .. Felix handles several *million* threads. (TCP) socket I/O is done the same way ZMQ does it: in a background thread. ZMQ sockets in Felix currently block the containing pthread, which is no good. To fix that the I/O will be lifted into a background thread. So it is *guaranteed* the I/O will happen in a different thread to the one that created the socket :) But still I doubt any extra locks are required at present since ALL the I/O is done in the background. OTOH if I do what 0MQ does -- and provide more than one background thread, I may need interlocking. It's likely applications such as a webserver will have a set of waiting fibres (one per connection or more), and they'll be farmed out to an arbitrary p-thread allocated from a pool. In that case, how can the client possibly obey the Rule since they have no control over which p-thread does the work? if you're stuck writing applications in C from the ground up you may well have the design control to obey the Rule but you can't assume people using advanced languages or frameworks, including stuff like Python, will have that kind of control. 0MQ isn't the only way to make multi-threaded programming safer. It needs to be able to fit in with other technologies. John, I am glad you have joined the 0mq community. It thrives on new ideas, fresh blood and motivated programmers. You are all three. But (you knew there was a but coming, right?) you still don't grok it. When I first wrote the Ruby bindings, I used it as an exercise to learn the library. I translated a few of the examples, got them running and was pretty pleased with myself. Then I decided to write a real app using the bindings. At least 6 months later, it occurred to me that without that first real and non-trivial application, I didn't really know 0mq at all. I certainly was comfortable with the concepts and their usage, but trying to get the code to work in a useful manner was the acid test. As far as I can see, you haven't even finished your Felix bindings but you are participating in at least 3 threads on this list with very strong opinions on how to change libzmq. What's worse is that you could solve the issues you mention above without a single change to libzmq. As the author of your binding, you can choose to present any reasonable api to your users. That facade can perform all manner of locking (memory barriers) to make massively-multithreaded code safe and to shield your Felix users from the underlying complexity. Try to do this with the current constraints that libzmq places on you and see how far you get. At this time, we have bindings for every major language (C, Java, Ruby, Python, LISP, OCaml, Lua, Erlang) many of which have runtimes that have additional limitations when using C-based libraries like libzmq. If those myriad runtimes and languages can somehow support libzmq safely and efficiently *without changing* libzmq, then I think you can figure out how to do the same for Felix. Please, please finish your bindings and *write at least one real non-trivial application* before you form too many strong opinions about how libzmq should change. I hope you don't take my suggestion as being rude. I do not intend it that way. Also, don't abandon us. We need you and others like you, but we need you better informed. cr ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On 03/02/2012, at 4:31 AM, Gleb Peregud wrote: Looks like Felix has processes/threads/fibers similar to Erlang processes. There is some similarity, but Erlang is exclusively message passing, whereas Felix supports shared memory. In fact, fibres represent logical threads of control in the same memory environment, and are interleaved under user program control so that shared memory access at the lower levels is guaranteed to be safe. Erlang does this interleaving as well, but it's an implementation detail, and deliberately: it is what allows you to move some of the processes into real OS processes or even off shore to other machines, without any code changes. You can't do that with Felix fibres or pthreads. In fact, Felix already has asynchronous socket I/O where the client code blocks fibres but not pthreads. The webserver on the website uses that: in theory it can support massive numbers of connections at the highest possible performance (that can be delivered by a single CPU). Context switching fibres outperforms OS pthread context switches, probably at least 1000 times faster, and there is no effective limit on the number of fibres (they're very lightweight, basically a single pointer is kept in a list). The main problem is that this is a stream model, like the underlying sockets support and that basically sucks: there's no framing. Which means applications have to agree on a framing protocol to communicate since most applications require messages not streams (even streaming protocols!) 0MQ solves that problem nicely by providing a standardised framing protocol, and at the Posix API like level. My problem is to make that work with fibres, but that has nothing to do with the thread safe API proposal. I just like theoretical challenges :) The ts proposal is more like: if you really want to get 0MQ into Posix you probably need to have a thread safe variant. No one is going to accept something that isn't at least optionally thread safe these days. It is OK for msg objects because they're transient in some sense IMHO, but there needs to be support for thread safe sockets (even if no one who know what they're doing ever uses them!). Actually ts sockets as proposed may be very useful debugging, since it eliminates one kind of possible error, temporarily. -- john skaller skal...@users.sourceforge.net ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Thu, Feb 2, 2012 at 3:44 PM, Chuck Remes cremes.devl...@mac.com wrote: As far as I can see, you haven't even finished your Felix bindings but you are participating in at least 3 threads on this list with very strong opinions on how to change libzmq. Oh, I think you're explaining it wrong... :-) We welcome all patches. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Feb 2, 2012, at 2:23 PM, Pieter Hintjens wrote: On Thu, Feb 2, 2012 at 3:44 PM, Chuck Remes cremes.devl...@mac.com wrote: As far as I can see, you haven't even finished your Felix bindings but you are participating in at least 3 threads on this list with very strong opinions on how to change libzmq. Oh, I think you're explaining it wrong... :-) We welcome all patches. Following your lead on this, all I can say at this point is that I think it's very difficult to create a patch that does what Mr. Skaller suggests. Actually, it's probably impossible. cr ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Thu, Feb 2, 2012 at 9:36 PM, Chuck Remes cremes.devl...@mac.com wrote: Following your lead on this, all I can say at this point is that I think it's very difficult to create a patch that does what Mr. Skaller suggests. Actually, it's probably impossible. Probably impossible, indeed. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On 02/02/2012 10:05 PM, Chuck Remes wrote: Lastly, I think it's time to trot out an old blog post that Martin Sustrik wrote on this topic. http://www.zeromq.org/blog:multithreading-magic To give the respect where it belongs, it was Pieter who wrote the article. I've only supplied the initial list of bullet points to cover. My writing skills are no match to Pieter's :) Martin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On 03/02/2012, at 1:44 AM, Chuck Remes wrote: if you're stuck writing applications in C from the ground up you may well have the design control to obey the Rule but you can't assume people using advanced languages or frameworks, including stuff like Python, will have that kind of control. 0MQ isn't the only way to make multi-threaded programming safer. It needs to be able to fit in with other technologies. John, I am glad you have joined the 0mq community. It thrives on new ideas, fresh blood and motivated programmers. You are all three. But (you knew there was a but coming, right?) Of course :) you still don't grok it. I wrote the proposal to see what it would look like. That's good science. Given the goals you can critique it. Quite separately you can say if you think it is worthwhile. I can also critique it, I can't really say about its worth due to lack of experience. Just because you have written an app following the Rule doesn't make it the only way possible way to code, and in particular if the library doesn't have thread-safe sockets you have no experience with them either :) Ignoring multi-part message the extra complexity is non-existent: exactly one extra API call is required (zmq_ts_init_context). The cost for non-users exists, but is down to one test and one machine word with a simple interface or one test and no machine words with a bit more work. Given the extremely low cost, it's worth considering, don't you think? The real issue is with multi-part messages, but they're already a problem. trying to make that thread safe isn't a problem with the thread-safety proposal, its a problem with the multi-part message API. FYI: I have a problem with Felix because Felix has the Rule too and Felix's rule overrides anything in 0MQ. Felix says user code is not allowed to block pthreads. 0MQ send/recv block. Using async I/O isn't the idea either: the idea is that in Felix the fibres (coroutine) block, not the pthreads. This means that the I/O has to be done in a background thread. The foreground thread creates, owns, and does everything with all the data structures except blocking I/O. So I have two choices BOTH of which break the Rule necessarily: a) delegate the zmq_send/recv to the background thread, with async socket and zmq polling. Easy to implement but breaks the Rule. b) rewrite 0MQ so that when it does a TCP socket send/recv it delegates to the Felix I/O thread. This makes using the library completely transparent. But it makes maintenance hard, if not impossible and it would be a lot of work. The existing binding just blocks .. but it won't do in the long term. Option (a) requires writing background handlers for 0MQ which is a pain, but it doesn't need the zmq_ts_context at all, there is already locking in place and the I/O will all be done in a single thread anyhow. So the proposal I made has nothing to do with Felix. -- john skaller skal...@users.sourceforge.net ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On 02/02/2012 11:23 PM, john skaller wrote: It's likely applications such as a webserver will have a set of waiting fibres (one per connection or more), and they'll be farmed out to an arbitrary p-thread allocated from a pool. In that case, how can the client possibly obey the Rule since they have no control over which p-thread does the work? if you're stuck writing applications in C from the ground up you may well have the design control to obey the Rule but you can't assume people using advanced languages or frameworks, including stuff like Python, will have that kind of control. 0MQ isn't the only way to make multi-threaded programming safer. It needs to be able to fit in with other technologies. The conclusion IMO, is that when you are designing a new application from ground up, you can use The Rule and what you get in reward is effortless scaling. However, when you are interfacing with a non-0MQ component with its own threading model (language runtime, web server, legacy application etc.) there's often no way to follow The Rule. In such case synchronised access to 0MQ sockets may be needed. The only two questions to answer are whether synchronisation should be enforced in all scenarios (along with the associated overhead) and whether such synchronisation should be part of 0MQ itself at all (as opposed to used synchronising the access himself). Martin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Fri, 3 Feb 2012 00:39:39 +1100 john skaller skal...@users.sourceforge.net wrote: BTW: are you so sure performance will suffer? Yes. The reason I ask is related to existing overheads: (a) malloc/free is used extensively in real applications, it is already thread-safe so it is using at least some combination of locks and TLS libzmq goes to great lengths to optimise memory allocation where possible. See e.g. the VSM functionality. There is several *years* tuning work that has been done on this. (b) the use of errno by 0MQ is a performance overhead already: errno is in TLS which has a nasty overhead. If you want to improve performance give up on, or at least provide a sane alternative to, errno. One extra indirection per load, that has nowhere near the overhead of a lock. Or does TLS do something more than that? If so, why? Fast barriers are provided on multi-cores, implemented directly in the hardware. There are also lock free synchronisation primitives on all modern CPUs. ^^ Primitives yes. You still need to implement the full lock free algorithms, e.g. ypipe_t. Speaking from experience, getting lock free algorithms right is really hard. -mato -- Martin Lucina mar...@lucina.net ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On 03/02/2012, at 7:36 AM, Chuck Remes wrote: On Feb 2, 2012, at 2:23 PM, Pieter Hintjens wrote: On Thu, Feb 2, 2012 at 3:44 PM, Chuck Remes cremes.devl...@mac.com wrote: As far as I can see, you haven't even finished your Felix bindings but you are participating in at least 3 threads on this list with very strong opinions on how to change libzmq. Oh, I think you're explaining it wrong... :-) We welcome all patches. Following your lead on this, all I can say at this point is that I think it's very difficult to create a patch that does what Mr. Skaller suggests. Actually, it's probably impossible. I know it's difficult sometimes to explain negative things, but can you indicate why, when one respondent considers wrapping the API with locks is easy enough, you consider simply embedding the locking inside the functions impossible? Of course I'm not even going to look at the code if there's no demand for thread safe sockets. I also asked a question earlier that didn't seem to get answered: what is the attitude introducing a dependence on a foreign library? (Source can be included in zmq without licence issues). In this case, Judy, since that determines the overhead. -- john skaller skal...@users.sourceforge.net ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On 03/02/2012, at 11:52 AM, Martin Sustrik wrote: On 02/02/2012 11:23 PM, john skaller wrote: [] The conclusion IMO, is that when you are designing a new application from ground up, you can use The Rule and what you get in reward is effortless scaling. If you're writing it in C or say C++ which have similar low level object models. fun take-with=grains of salt The thing is .. you mention below legacy applications and .. well .. from my point of view anyone writing C or C++ is dealing with a legacy language. If you're really doing stuff from the ground up you'd be mad to use C as a programming language and C++ is not much better, just as you'd be mad to use TCP sockets when you have ZMQ. The problem then is that your argument then falls apart: if you're doing ground up stuff you're already giving up the control you mention and if you're doing legacy stuff you already have the interfacing issues you mention, so actually the Rule is broken in *both* cases :) /fun However, when you are interfacing with a non-0MQ component with its own threading model (language runtime, web server, legacy application etc.) there's often no way to follow The Rule. In such case synchronised access to 0MQ sockets may be needed. Yes, in fact, even in Felix, which is a C/C++ object model language, there is a need to get at some of the internals which aren't exposed: I like the API for the framing, but I need to eliminate all pthread blocking operations. I don't see a way to do that at the moment. The zmq_poll is the closest but the select-like API won't scale, and it's not clear I can implement, say zmq_msg_send() in terms of itself with non-blocking sockets and zmq_poll either (haven't really looked yet). The only two questions to answer are whether synchronisation should be enforced in all scenarios (along with the associated overhead) and whether such synchronisation should be part of 0MQ itself at all (as opposed to used synchronising the access himself). That's a fair analysis IMHO, and it would be best to resolve it by considering an actual implementation or two. -- john skaller skal...@users.sourceforge.net ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On 03/02/2012, at 11:55 AM, Martin Lucina wrote: One extra indirection per load, that has nowhere near the overh It's implementation dependent of course. I have no idea how say GNU does it on say Linux. An obvious fast way to do it is allocate a mapped VM page for every thread. Cost: 4K (page size). Then the hardware mapping will context switch automatically, at some cost to context switches. Another way to do it would be to use traps, and then use Posix TLS: that's extremely slow (you're getting and setting values by a string key if I recall .. gak!) Also there's a serious overhead in all these cases added if you're using a shared library, since the library can't know the address of errno, you need extra indirections, just as you do for *all* global memory. Fast barriers are provided on multi-cores, implemented directly in the hardware. There are also lock free synchronisation primitives on all modern CPUs. ^^ Primitives yes. You still need to implement the full lock free algorithms, e.g. ypipe_t. Speaking from experience, getting lock free algorithms right is really hard. *If* it were possible to use it in 0MQ that would be an argument for putting it in the core of ZMQ instead of making the user do it. I have no idea if any of the operations could benefit from it. The one that comes to mind would be maintaining the trie in the PUB sockets. You might get away with that without needing locks if you used the right kind of tree, I don't know. -- john skaller skal...@users.sourceforge.net ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Feb 2, 2012, at 7:49 PM, john skaller wrote: On 03/02/2012, at 7:36 AM, Chuck Remes wrote: On Feb 2, 2012, at 2:23 PM, Pieter Hintjens wrote: On Thu, Feb 2, 2012 at 3:44 PM, Chuck Remes cremes.devl...@mac.com wrote: As far as I can see, you haven't even finished your Felix bindings but you are participating in at least 3 threads on this list with very strong opinions on how to change libzmq. Oh, I think you're explaining it wrong... :-) We welcome all patches. Following your lead on this, all I can say at this point is that I think it's very difficult to create a patch that does what Mr. Skaller suggests. Actually, it's probably impossible. I know it's difficult sometimes to explain negative things, but can you indicate why, when one respondent considers wrapping the API with locks is easy enough, you consider simply embedding the locking inside the functions impossible? I can't imagine how it would be done cleanly. I haven't thought about it as deeply as you, but in my experience this will be very difficult if not impossible to achieve. I welcome being proven wrong. :) Of course I'm not even going to look at the code if there's no demand for thread safe sockets. I have yet to see anyone in this thread demand it. This lack of demand may yet save you from the work! I also asked a question earlier that didn't seem to get answered: what is the attitude introducing a dependence on a foreign library? (Source can be included in zmq without licence issues). In this case, Judy, since that determines the overhead. I am not a license (or a British licence) expert. I'll defer to others to chime in. cr ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On 03/02/2012, at 2:32 PM, Chuck Remes wrote: I can't imagine how it would be done cleanly. I haven't thought about it as deeply as you, but in my experience this will be very difficult if not impossible to achieve. I welcome being proven wrong. :) Can you explain why simply setting a mutex at the start of every C API call, and releasing it at the end, would not work? the mutex object would live in the socket. Given that, making the set and release of the mutex conditional on a flag, also in the socket, could be done, and the flag can clearly be inherited from the context that creates it. Of course I'm not even going to look at the code if there's no demand for thread safe sockets. I have yet to see anyone in this thread demand it. This lack of demand may yet save you from the work! True :) However there's a caveat: people regularly say I don't need that, I have worked without it, why would I need it. They say it because they don't have the alternative available to try. Why would you need C++? People have been programming successfully in C for ages and ages! Actually .. no they haven't. They just think they have been, they have no idea at all how bad their code is and how inefficient they are by comparison .. because they have no comparison. I also asked a question earlier that didn't seem to get answered: what is the attitude introducing a dependence on a foreign library? (Source can be included in zmq without licence issues). In this case, Judy, since that determines the overhead. I am not a license (or a British licence) expert. I'll defer to others to chime in. I'm saying there's no licence issue (I know the developer and he can make sure there is no issue and I feel would do so!). The fundamental question is whether ZMQ should have a third party library in it. There's good reason to NOT do this. Felix has the policy of not depending on external third party libraries, we DO use Judy, so we actually submodule the sources and build it as part of Felix. But it is still a 3PL in that if it had a bug there's no way I could fix it. It's a risk. I took it because its used in the GC to track every memory allocation so we need the best available data structure, and that is appears to be Judy1/JudyL arrays. If the decision is not to depend on any 3PLs such as Judy I can understand and live with the consequences: homebrew code will never be as good, but it is maintainable. I just don't want to have a go at a patch where *I* would use Judy and find it is rejected because of that, when I could have used a STL::map instead. Or where using an STL::map would make the performance untenable (Judy arrays are an order of magnitude or more faster for this particular requirement). So I'd rather prune the possible implementations before starting on one :) -- john skaller skal...@users.sourceforge.net ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] C++ assertion failed with Java client
On Feb 2, 2012, at 11:21 PM, john skaller wrote: On 03/02/2012, at 2:32 PM, Chuck Remes wrote: I can't imagine how it would be done cleanly. I haven't thought about it as deeply as you, but in my experience this will be very difficult if not impossible to achieve. I welcome being proven wrong. :) Can you explain why simply setting a mutex at the start of every C API call, and releasing it at the end, would not work? the mutex object would live in the socket. I don't understand all the constraints of your Felix language, so anything I guess at would likely be wrong. That said, a single mutex for thousands (tens of thousands, millions?) of Felix threads/fibers would likely not work well. I can't imagine how that would scale to 24, 48, 96+ processors. Like I said earlier: impossible. Of course I'm not even going to look at the code if there's no demand for thread safe sockets. I have yet to see anyone in this thread demand it. This lack of demand may yet save you from the work! True :) However there's a caveat: people regularly say I don't need that, I have worked without it, why would I need it. They say it because they don't have the alternative available to try. Why would you need C++? People have been programming successfully in C for ages and ages! Actually .. no they haven't. They just think they have been, they have no idea at all how bad their code is and how inefficient they are by comparison .. because they have no comparison. I agree wholeheartedly. That's why I program in a nice high-level lang like Ruby. I gave up on C C++ about 15 years ago and have never regretted one instant of it. I also asked a question earlier that didn't seem to get answered: what is the attitude introducing a dependence on a foreign library? (Source can be included in zmq without licence issues). In this case, Judy, since that determines the overhead. I am not a license (or a British licence) expert. I'll defer to others to chime in. I'm saying there's no licence issue (I know the developer and he can make sure there is no issue and I feel would do so!). Again, I have no opinion. I'll allow others to voice theirs. cr ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] C++ assertion failed with Java client
Hello All, I am receiving the following errors when I try to work in a multi-threaded environment (10 threads) where ZeroMQ is used to send/receive messages Assertion failed: ok (..\..\..\src\mailbox.cpp:79) Assertion failed: ok (..\..\..\src\mailbox.cpp:79) Assertion failed: ok (..\..\..\src\mailbox.cpp:79) Assertion failed: ok (..\..\..\src\mailbox.cpp:79) Assertion failed: nbytes == sizeof (dummy) (..\..\..\src\signaler.cpp:203) Assertion failed: ok (..\..\..\src\mailbox.cpp:79) Assertion failed: ok (..\..\..\src\mailbox.cpp:79) Assertion failed: ok (..\..\..\src\mailbox.cpp:79) Assertion failed: ok (..\..\..\src\mailbox.cpp:79) Assertion failed: ok (..\..\..\src\mailbox.cpp:79) Please let me know if we can use ZeroMQ api with multi threading? Also is there a limit on number of threads that can be spawned? Regards, Kishore ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
