Modify

Opened 12 years ago

Closed 10 years ago

#431 closed Bugs (fixed)

boost jam problem with parallel builds

Reported by: alx_s Owned by: René Rivera
Milestone: Boost.Jam 3.1.15 Component: bjam
Version: Boost.Jam 3.1.14 Severity: Problem
Keywords: Cc:

Description (last modified by René Rivera)

OK, this bug makes my life miserable for a long, long
time. :)

In short, if I have an action which updates more then
one target then I have problem with parallel build.

Attached is a simple testcase. Just run 'jam -j2' and
you can notice that target 'g2.generated' is been used
before it is updated (created).

The testcase has just 2 rules - 'Gen' models generating
2 files which are used by 'Use'.
The testcase doesn't actually create any files, but
that doesn't matter. Jam works with targets, not files.

The last line in the Jamfile is a workaround. If you
uncomment it, the test works fine.

I spent some time trying to find the reason and to fix
the bug, but succeed only in the first part.

I can discuss it in more details with someone
interested in fixing it. I just didn't get enough time
to fix the bug by myself.

Attachments (1)

Jamfile (480 bytes) - added by René Rivera 10 years ago.
Original testcase from SF tracker.

Download all attachments as: .zip

Change History (9)

comment:1 Changed 12 years ago by René Rivera

Logged In: YES 
user_id=33595

As intended. The dependency graph of your example looks
something like:

u1.user -> g1.generated
u2.user -> g2.generated

The fact that g1.generated and g2.generate are produced by 1
action is irrelevant. You need to change the code so the
dependency graph looks like:

u1.user -> g1.generated
u1.user -> g2.generated
u2.user -> g1.generated
u2.user -> g2.generated

Which you can do by changing the Use rule invocations to:

Use u1.user : g1.generated g2.generated ;
Use u2.user : g1.generated g2.generated ;

HTH.

comment:2 Changed 12 years ago by alx_s

Status: assignedclosed
Logged In: YES 
user_id=445009

As intended what? I didn't get you.

You are right about dependency graph. It does look like:

u1.user -> g1.generated
u2.user -> g2.generated

And you are right that the fact that g1.generated and
g2.generate are produced by 1 action _should_ be irrelevant.
But it's not. That is the problem. If they are produced by
one action, then I have a problem with parallel builds. If
they are produced by separate actions - all is fine.

Just look at the line you wrote: 

u2.user -> g2.generated

That means that g2.generated should be updated before
u2.user. Right? But this is not the case if parallel build
is used. Changing dependency graph as you suggested helps,
but it doesn't fix the problem. It is just a workaround.

Regards,
Alexey Sarytchev

comment:3 Changed 12 years ago by René Rivera

Logged In: YES 
user_id=33595

Hm, sorry I see what you mean now. I though you where
talking about a new problem. But it's just one of the
existing bugs/limitations of the original Perforce/Jam. See
the "BUGS, LIMITATIONS" section of
http://public.perforce.com/public/jam/src/Jam.html
(http://64.233.187.104/search?q=cache:fDuhra5lsswJ:public.perforce.com/public/jam/src/Jam.html+BUGS+LIMITATIONS&hl=en).

Yea, I know it's not much of a consolation :-( I can't
promise a fix any time soon, as I don't see any generic easy
solution, but I'll work on it.

comment:4 Changed 12 years ago by alx_s

Logged In: YES 
user_id=445009

Yes, I know it a known bug in the original Jam. :)
It just looks like nobody is working on it there. So I
decided to submit it for boost jam as it looks like it is
more actively developed. And did that with a simple testcase
which shows the problem. It didn't looked too hard to fix
for me when I figured out what was the cause, but just
required a better knowledge of the some sort of state
machine used by Jam to update targets. So I thought maybe
someone with that knowledge could finally fix it.

Regards,
Alexey Sarytchev

comment:5 Changed 11 years ago by René Rivera

Component: Nonebjam

comment:6 Changed 11 years ago by René Rivera

Description: modified (diff)
Severity: Problem
Version: NoneBoost.Jam 3.1.14

Changed 10 years ago by René Rivera

Attachment: Jamfile added

Original testcase from SF tracker.

comment:7 Changed 10 years ago by René Rivera

Milestone: Boost.Jam 3.1.15

comment:8 Changed 10 years ago by René Rivera

Resolution: Acceptedfixed
Status: assignedclosed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain René Rivera.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.