Re: [Boost-build] question(s) about bjam code

Subject: Re: [Boost-build] question(s) about bjam code
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-10-27 18:39:07

Hi Steven,

following up on this exchange...

On 13.10.2017 10:55, Stefan Seefeld wrote:
> On 13.10.2017 10:45, Stefan Seefeld wrote:
>> On 05.10.2017 22:31, Steven Watanabe via Boost-build wrote:
>>> AMDG
>>>
>>> On 10/05/2017 08:12 PM, Stefan Seefeld via Boost-build wrote:
>>>> <snip>
>>>> I'm looking at 
>>>> https://github.com/boostorg/build/blob/develop/src/engine/make1.c#L326, and 
>>>> wonder why, despite the inline comment above the referenced line, this is not 
>>>> the first statement to be executed in the make1a function. I understand that the 
>>>> make1a function may be called multiple times from different locations, but 
>>>> should be ignored (i.e., should be a noop) in all but one case.
>>>>
>>>> However, each time the function is called, its parent's async counter is 
>>>> incremented (as long as this target 's progress is not yet RUNNING).
>>>>
>>> Example:
>>>
>>> A depends on C
>>> B depends on C
>>>
>>> We enter make1a for C twice, once with each parent,
>>> A and B.  A and B both need to wait for C to complete,
>>> hence we increment the async counter both times.
>>>
>>> We only skip this if C has already completed, and
>>> no waiting is required.
>>
>> Fair enough. However, if the parent counter is incremented, shouldn't
>> there also (directly or indirectly) be a MAKE1B state that is pushed
>> onto the stack for that parent ?
>> This happens if the child target hasn't started processing, but it
>> doesn't if it's already on the stack.
>
> Never mind, I think I see where this happens:
> https://github.com/boostorg/build/blob/develop/src/engine/make1.c#L649-L657

so an async counter being set to NÂ  for target T means there are N
prerequisite targets "in flight". For this state machine, "in flight"
means that there are N `make1B` states for T either already on the
stack, or eventually will be (pushed from prerequisites). Correct ?

I'm debugging a case where that assumption (invariant ?) is broken
(leading to a build process that suddenly stops), and I wonder where the
logic error is...
(I'm trying to capture the state machine logic in a UML state diagram in
an attempt both to document and to understand, but find the actual logic
very elusive due to the async stuff. Any idea what formal language
(doesn't have to be UML) might be useful to capture the state machine in
pseudo-code ?)

Thanks,

Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...