[zeromq-dev] cookbook project

2016-02-12 Thread Adriano Ribeiro
Hi fellows, Last year i started to contribute with the zeromq cookbook, but
for me this project cannot compete with zguide, for me the zguide is our
zmq code sample reference book and the cookbook should be a zmq solutions
reference book because of this, i think that our cookbook is lost.

I made few structural changes to allowing scale solutions with references
implementations in multiple languages. For now i started to use mkdocs to
build the markdown-based site, like http://netmq.readthedocs.org/en/latest/.
I stopped to think a way to our cookbook become interesting to people like
the zguide.

My propose to cookbook repository:

/index.md - solutions index
/solution_home_folder/
/solution_home_folder/index.md - solution presentation documents, diagrams,
etc...
/solution_home_folder/code - code informations about the solution
/solution_home_folder/code/index.md - implementations list to a given
solution, we can have several implementation to one language not just an
absolute implementation to evolve.
/solution_home_folder/code/go/ - implementation's home
/solution_home_folder/code/go/src - source code implementation's home
/solution_home_folder/code/go/index.md - changelog to every implementation
/solution_home_folder/code/python/
/solution_home_folder/code/python/index.md
/solution_home_folder/code/python/src
.
.
.
/another_solution_home_folder/

Att,
Adriano Ribeiro
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] More examples for zguide and tornado and asyncio ioloop

2016-02-12 Thread Pieter Hintjens
Yes, please, send pull requests to the Guide repo. Thanks!

On Fri, Feb 12, 2016 at 7:49 PM, Dave Kuhlman  wrote:
> I've taken some of the Python examples in the zguide and have
> adapted them for Python 3 and the async style.  I've done this both
> for use with the tornadoweb ioloop and the asyncio ioloop.
>
> I'm hoping that these examples might be useful to other ZeroMQ
> Python programmers who might be struggling to use the async style.
>
> While I am definitely not an expert in this area, these modified
> examples seem to run OK.  But, they do need some vetting by someone
> who has a deeper understanding than I do.
>
> You can find them here: https://github.com/dkuhlman/zguide.git
>
> Look under:
>
> - examples/Python/tornado_ioloop
> - examples/Python/asyncio_ioloop
>
> If someone else thinks this example code is worth including in the
> zguide and is willing to review it, that'd be great.  And, I'm
> willing to do more work on it.
>
> I can send a pull request on Github, when and if that's helpful.
>
> Dave
>
> --
>
> Dave Kuhlman
> http://www.davekuhlman.org
> ___
> 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


[zeromq-dev] More examples for zguide and tornado and asyncio ioloop

2016-02-12 Thread Dave Kuhlman
I've taken some of the Python examples in the zguide and have
adapted them for Python 3 and the async style.  I've done this both
for use with the tornadoweb ioloop and the asyncio ioloop.

I'm hoping that these examples might be useful to other ZeroMQ
Python programmers who might be struggling to use the async style.

While I am definitely not an expert in this area, these modified
examples seem to run OK.  But, they do need some vetting by someone
who has a deeper understanding than I do.

You can find them here: https://github.com/dkuhlman/zguide.git

Look under:

- examples/Python/tornado_ioloop
- examples/Python/asyncio_ioloop

If someone else thinks this example code is worth including in the
zguide and is willing to review it, that'd be great.  And, I'm
willing to do more work on it.

I can send a pull request on Github, when and if that's helpful.

Dave

-- 

Dave Kuhlman
http://www.davekuhlman.org
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


[zeromq-dev] Gyp build for libzmq

2016-02-12 Thread Pieter Hintjens
Hi all,

Just a FYI, there's a new build process, in builds/gyp.

This builds libzmq (static) for Linux, OS/X, and Windows. It's part of
the work to make a new node.js stack.

It works on these three platforms. We'll now be porting that into zproject.

-Pieter
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] ZeroMQ thread safety (or not)

2016-02-12 Thread Pieter Hintjens
You can move sockets from one thread to another if you do the right magic.

We're developing a new family of sockets (client-server, radio-dish)
that are fully threadsafe.

On Fri, Feb 12, 2016 at 1:47 PM, Alex Bligh  wrote:
> I am attempting to write a Go Channel wrapper (similar to vaughan0's work but 
> working on top of the pebbe's go bindings), as I'm using zmq in an 
> environment where I will often want to use a golang 'select' mixing zmq 
> sockets and other golang channels. I have a question about thread safety.
>
> The ZeroMQ guide says: "Remember: Do not use or close sockets except in the 
> thread that created them.". I want to know whether this is in fact a 
> prohibition.
>
> In Vaughan0's GoLang bindings, the MakePair function creates a pair of PAIR 
> sockets in one thread:
>   https://github.com/vaughan0/go-zmq/blob/master/util.go#L24
>
> Each end of this pair is then passed to a different goroutine (thread-ish) 
> here:
>   https://github.com/vaughan0/go-zmq/blob/master/channels.go#L34
>
> (i.e. ProcessOutgoing uses outsock, ProcessSockets uses insock)
>
> This is a pretty useful thing to do. Is it permissible?
>
> Specifically is the following pattern permissible?
>
>  Thread 1Thread 2
>  
>
>  Create socket
>  Connect() / Bind()
>  Pass details to thread 2
>  Never access socket again
>  Use socket to read/write
>  Close socket
>
> This is essentially what the vaughan0 golang bindings are doing.
>
> I understand completely that using the same socket in two threads at once is 
> NOT permissible. However, unless the sockets are using thread local variables 
> (which is going to be problematic in go as the same goroutine can be 
> scheduled between different OS threads) I can't immediately see why the above 
> would not work.
>
> --
> Alex Bligh
>
>
>
>
> ___
> 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


[zeromq-dev] ZeroMQ thread safety (or not)

2016-02-12 Thread Alex Bligh
I am attempting to write a Go Channel wrapper (similar to vaughan0's work but 
working on top of the pebbe's go bindings), as I'm using zmq in an environment 
where I will often want to use a golang 'select' mixing zmq sockets and other 
golang channels. I have a question about thread safety.

The ZeroMQ guide says: "Remember: Do not use or close sockets except in the 
thread that created them.". I want to know whether this is in fact a 
prohibition.

In Vaughan0's GoLang bindings, the MakePair function creates a pair of PAIR 
sockets in one thread:
  https://github.com/vaughan0/go-zmq/blob/master/util.go#L24

Each end of this pair is then passed to a different goroutine (thread-ish) here:
  https://github.com/vaughan0/go-zmq/blob/master/channels.go#L34

(i.e. ProcessOutgoing uses outsock, ProcessSockets uses insock)

This is a pretty useful thing to do. Is it permissible?

Specifically is the following pattern permissible?

 Thread 1Thread 2
 

 Create socket
 Connect() / Bind()
 Pass details to thread 2
 Never access socket again
 Use socket to read/write
 Close socket

This is essentially what the vaughan0 golang bindings are doing.

I understand completely that using the same socket in two threads at once is 
NOT permissible. However, unless the sockets are using thread local variables 
(which is going to be problematic in go as the same goroutine can be scheduled 
between different OS threads) I can't immediately see why the above would not 
work.

-- 
Alex Bligh




___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev