Problems using java.util.concurrent thread pools

I’m playing around with ffi-rzmq which provides bindings to 0mq. I
have a block of code that I run in a thread that creates a 0mq socket
and then just loops forever reading and writing to it.

Pseudo code…

@thread_pool = java.util.concurrent.Executors.newFixedThreadPool(20)
20.times {@thread_pool.execute({ 0mq code })

This causes a segfault in the 0mq library where it tries to create a
socket.

20.times {Thread.new { same 0mq code }}

This works.

0mq sockets are not thread safe, the rule is your 0mq socket must live
in one and only one thread. I was wondering if they might be using
calls to get the thread id, and those somehow behave differently
inside jruby? It’s a wild guess.

Chris


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

On Oct 6, 2010, at 5:41 PM, snacktime wrote:

calls to get the thread id, and those somehow behave differently
inside jruby? It’s a wild guess.

Interesting…

Do you have a complete example that I could run? If so, throw it up on
pastie.org or gist.github.com and point me to it.

cr


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

On Wed, Oct 6, 2010 at 4:08 PM, Chuck R. [email protected]
wrote:

Interesting…

Do you have a complete example that I could run? If so, throw it up on pastie.org or gist.github.com and point me to it.

I’ll see about taking some sample code from the gem and running it the
same way to see if it breaks, that would make a simple test case… My
code works against an existing server that talks 0mq (mongrel2), so
it’s not really suited for a test case as it uses external ruby files
and only deals with one endpoint.

Chris


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

On Oct 7, 2010, at 1:00 PM, snacktime wrote:

it’s not really suited for a test case as it uses external ruby files

Not jruby specific, but kind of interesting.

Very odd. If you have a reproducible case, you should send it on to the
0mq guys.

Alternately, try using the latest git master and see if the problem
persists. This may have been solved with some of the rewrite to support
migrating sockets between threads, changing socket closing semantics,
etc.

cr


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

On Wed, Oct 6, 2010 at 4:24 PM, snacktime [email protected] wrote:

and only deals with one endpoint.
Ya so that didnt’ work, it’s something in my particular code, which
has changed enough that I can’t replicate the previous error.

But now I’m seeing exactly what this thread talks about when using any
of the shutdown related commands for the thread pool, it makes my 0mq
context just disappear.

http://comments.gmane.org/gmane.network.zeromq.devel/2228

Not jruby specific, but kind of interesting.

Chris


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs