(I'm CCing the MacRuby list just in case someone would be looking for the same answer. You can definitely do threads, but the easiest way would be to use IO.popen: $> macruby -e 'io = IO.popen("sleep 5"); p Process.waitpid(io.pid, 0)' 56484 You can of course use Process.WNOHANG instead of 0. Please note that if you have an array of arguments (like in your example), you can pass an array to popen and splat your arguments in it: $> macruby -e 'args = ["blah", "bleh", "meh", "hohoho"]; io = IO.popen(["echo", "moof", *args]); p Process.waitpid(io.pid, 0); p io.gets' 56505 "moof blah bleh meh hohoho\n" I hope this helps :-) -- Thibault Martin-Lagardette On Jun 4, 2010, at 15:29, macruby@djc.net wrote:

Very good, thanks. If you don't mind: what is the recommended way of migrating code that does use fork, but in fact, is just doing fork/exec, e.g.

the code used to do p1 = fork { exec(*ARGV) <---- some foreign binary/cmd }

to get the process id, NOT block, and later, at the appropriate time, do something like

Process.waitpid(p1) or Process.waitpid(p1,Process::WNOHANG)

is an alternative recommended:

Open4#popen4 ? will that work in MacRuby?

else threads + `` ?

or another alternative?

On Fri, 4 Jun 2010 14:57:51 -0700 Thibault Martin-Lagardette <thibault.ml@gmail.com> wrote:

...

Hi! MacRuby makes intensive use of many system Frameworks and libraries, which makes us limited by the CAVEATS of fork(). What it means for us, is that we can use fork() for the typical pipe+dup2+fork+exec (any exec from the exec family) to run a binary and read its output. That's what we use for #` (well we actually use posix_spawn, but it is equivalent). But callin the exec() family is pretty much all we can safely do within a forked program. Because of the said caveats, we cannot do any kind of ruby execution, not even "just" calling #exec, since it would use the MacRuby dispatcher, the Obj-C runtime etc. This makes it impossible for us to implement the "|-" argument to #read / #open, or the #fork method. The main problem is that CoreFoundation would be involved within the two processes and share, for example, the same garbage collector. What is not safe is using anything related to CoreFoundation within the new forked process (we could say it's not "fork-safe"), and the dispatcher as well as the MacRuby runtime make extensive use of Foundation / CF. Even if the only operation within the child would be simply calling #exec (which we cannot make sure of anyway), calling this method would go through the runtime and the dispatcher, unfortunately unsafe. I hope this explains it :-) -- Thibault Martin-Lagardette On Jun 4, 2010, at 14:50, macruby@djc.net wrote:

...

Just curious: why was MacRuby added to the not-support list for fork() : Changeset 3398: mark Process.fork as not supported-implemented. Is there some subtle issue that will keep this from being implemented? -Daniel _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel