I'm totally dissatisfied with modern state of concurrency support in dynamic languages:
About Ruby:
MRI Ruby Threads are native but interpreter itself has blocking nature. The list of really concurrent-powered Ruby implementations is pretty short: #Rubinius (#LLVM Ruby implementation), #JRuby (built on top of #Java VM with using of support for dynamic languages). Not sure about #MacRuby (built on #LLVM also). With MRI problem can be solved with using C binding with calculation-intensive work in combination with rb_thread_blocking_region Ruby C API method.
About Perl:
Perl has native threads inside its Linux port. Moreover, concurrency issues in it is solved with using threads::shared mechanics. threads::shared is pragma-module. Is we don't use threads::shared then all data will be entirely and deeply copied for each thread creation. If we will provide variable :shared attribute then this particular blessed variable's instance will be accessible from all threads. But there are several BUT's:
- GLOBs references (read file descriptors) cannot be shared. Perl will argue then if you've decided to assign shared member or member's element to non-shared object;
- it follows from statement above that entire object must be deeply "shared" (all members should have internal shared attribute);
- several widely-used packages (Perl DBI for example) have issues with concurrency because of internally maintained singleton objects; sometimes they are claimed as "blocking and thread-safe" but I would say "sometimes for particular runs they will be save" from what I've observed recently in one of my unit tests. I would advise to give a chance for sufficient concurrency and you will see the issues.
No comments:
Post a Comment