Hello Michael. I'm one of the zeromq.node (aka zmq in npm) project collaborators. I see you've started developing a zmq-stream on github. I've played with it a bit and have found these issues/drawbacks/recommendations/etc:
1) You use only the uv_timer_* functions and no uv_poll_*. Why is that? 2) You may be interested in how I made better options handling some time ago: https://github.com/JustinTulloss/zeromq.node/pull/180 Main ideas are: we add "constants" for all the options disregarding of whether current libzmq have them; we let libzmq decide whether it can get/set these options; we set types for these options' values so that setsockopt and getsockopt become trivial; 3) I see you have Ref call in the constructor. Is it a bad idea for sockets that don't bind/connect anything and should be GCed asap? Zeromq.node had no ref at all but I added it with slightly different usage: https://github.com/JustinTulloss/zeromq.node/pull/199 4) If I run router.js 1000000 and then run dealer.js 1000000, dealer never finishes. It usually stops at something like this: > Got: 100 > Got: 63 > IN EAGAIN: 975463 > OUT EAGAIN: 992500 > READABLE > Got: 100 > DRAIN > Got: 100 > ... > Got: 100 > Got: 37 > IN EAGAIN: 984500 and that's it. Reproduces on xubuntu 12.10, node 0.8.22 and 0.10.2. 5) It generates a warning in the current master version with node 0.10.2: > CXX(target) Release/obj.target/zmqstream/src/zmqstream.o > ../src/zmqstream.cc: In static member function 'static > v8::Handle<v8::Value> zmqstream::Socket::GetOption(const v8::Arguments&)': > ../src/zmqstream.cc:83:35: warning: 'rc' may be used uninitialized in this > function [-Wmaybe-uninitialized] > ../src/zmqstream.cc:300:9: note: 'rc' was declared here Anyway, I like the project. Great work! I'll borrow some ideas for zeromq.node as well :) суббота, 9 февраля 2013 г., 0:45:32 UTC+7 пользователь Michael Schoonmaker написал: > > I want to make sure I'm not unnecessarily duplicating effort. > > The existing ZeroMQ library (https://npmjs.org/package/zmq) is > _perfect_ for a significant number of use cases. It handles a lot of > the low-level socket management for you, automatically emitting > 'message' events as new messages arrive. Awesome. > > While it was invaluable for developing the current version of Shuttle, > for the next version I want to further utilize the existing queue > mechanics inherent to ZeroMQ, and pull from sockets _manually_, rather > than automatically. (For reasons and examples, see the Guide. It's a > delightful read: http://zguide.zeromq.org/page:all) > > I'm planning on building a new set of ZeroMQ bindings that take > inspiration from the streams2 Duplex class, albeit reading and writing > in _messages_ rather than bytes (although it would be simple to write > a set of Transforms to make these pseudo-Duplexes behave more like > true streams2 Duplexes, fracturing the message frames back into > bytestreams. It seems like an odd use case, but is fortunately > workable). > > Is anyone planning on similar work, or should I continue unabated? > > -Schoon > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
