[Rake-devel] Rake 0.9.3.beta.2 with -j option

Jos Backus jos at catnook.com
Tue Oct 23 22:38:42 UTC 2012


On Tue, Oct 23, 2012 at 2:06 PM, Jim Weirich <jim.weirich at gmail.com> wrote:

>
> On Oct 23, 2012, at 4:34 PM, Jos Backus <jos at catnook.com> wrote:
> > It would trigger my OCD ;)
>
> <an aside>
> Saw a post that read: "I have CDO.  It's like OCD but with the letters in
> alphabetical order."
> </an aside>
>

Heh, good one.


>
> > <questions on drake>
>
> > Is this something the drake author could help gain certainty about?
>
> Oh, yes.  Certainly.  The fault is my own laziness.
>

Okay, just checking :)


>
> > <discussion of options>
> >
> > I like -m better, it avoids a future behavioral change conflict with -j.
>
> Michael's proposal introduces both a -j and -m flag.  The -j flag sets the
> thread pool size and the -m turns tasks into multi-task.  The drake
> behavior is to use -j to do both jobs and leave no way of setting the
> thread pool for multitasks.
>

Separating them sounds like it would give us more flexibility. All I was
worried about was mainly a change of semantics of -j down the road. This
approach avoids that, good to hear.


>
> > <problems with arbitrarily turning on multithreading>
> >
> > But would it not require users to specify some option? Iow, the default
> case would not be affected. And if someone specifies a new option, the
> documentation could point out that in the case of incomplete dependency
> specifications, recipes that depend on pure sequential operation for
> correctness could break, and the missing dependencies need to be specified.
>
> The problem is not incomplete dependency specifications, but using
> shared/mutable objects in tasks (that suddenly could be executed in
> multiple threads).  I doubt there is any completely safe way to do this in
> general, but would like to hear ideas on reducing risk.
>

Ah, so it's a general thread-safety issue.

Thanks, Jim.

Jos
-- 
Jos Backus
jos at catnook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rake-devel/attachments/20121023/444430fd/attachment.html>


More information about the Rake-devel mailing list