Hi,
2016-12-01 8:03 GMT+09:00 Martin Thomson <martin.thomson@gmail.com>:
> On 1 December 2016 at 00:05, Cory Benfield <cory@lukasa.co.uk> wrote:
>> My understanding of what Martin is suggesting is that that isn’t true:
>> blocked streams do not distribute their weight to their dependants.
However,
>> that’s also what the Python Priority implementation does.
>
> And this was my error in writing up the errata and my earlier emails.
> The spec is clear that there is no functional distinction between
> blocked and finished. The original text is correct.
>
> It's pretty obvious however that it's not clear. I'd answered on the
> basis of first principles, and that was an error on my part.
>
> Mike's algorithm is almost correct, but I would revise it. Starting
> at the top level:
>
> Given a set of dependents of S,
> find all S where not TreeBlocked(S) as S'
> allocate resources to S' proportional to their weights
> for a stream s in S', if StreamBlocked(s), repeat algorithm with
> its dependents
>
> Not treating closed as special keeps this simple. If you were to
> treat closed as different to blocked, then you have the issues that
> Cory was digging into.
>
> Kazuho points out:
>> I also do not see why it would be beneficial to treat them [closed
streams] differently.
>
> It's beneficial if you have other streams that are not blocked that
> don't have dependencies.
>
> Imagine that you have two HTML files and then images for each as
> dependents. If one HTML file is blocked, then there is potentially
> less value in loading the images that depend on it than there is in
> making progress on the other HTML file. Now, that is arguably not
> valuable because HTML/image dependencies are sort of loose, but if you
> have an application that has absolute dependencies (I can't use this
> until you give me that) and other constraints (not enough memory to
> buffer), then you can see a way to treating closed and blocked
> differently.
>
> Of course, that isn't what the spec says and we don't get to change that
:)
Thank you for explaining what you had in mind.
That makes sense, and _if_ we are going to fix the issue, I'd prefer adding
a feature to group multiple streams into one so that other streams can
depend against a group of streams.
In H2O, we internally promote CSS and JavaScript files in such way, e.g.:
+- CSS1 -+
root -+- CSS2 -+- HTML - ...
+- JS -+
I believe that adding an ability to designate this kind of dependency would
be better than adding special casing for blocked streams.
> BTW, in answer to what people suggested about flow control, that is
> only one reason a resource might be blocked. A resource might be
> blocked because the server hasn't finished building it, that might be
> IO or processing.
--
Kazuho Oku