Johannes Sixt <j6t@xxxxxxxx> writes:
> My findings so far are negative. The only short-term and mid-term
> solution I see so far is to opt-out from the framework during
> build-time.
Now, from where I sit, it seems that the way forward would be
1. Make this an optional feature so that platforms can compile it
out, if it is not already done. My preference, even if we go
that route, would be to see if we can find a way to preserve the
overall code structure (e.g. instead of spawning multiple
workers, which is why the code needs NONBLOCK to avoid getting
stuck on reading from one while others are working, perhaps we
can spawn only one and not do a nonblock read?).
2. After that is done, the feature could graduate to 'master'. As
this is a bigger framework change than others, however, we do
not necessarily want to rush it. On the other hand, because
this only affects submodules, which means it has fewer users and
testers that would give us feedback while it is on 'next', we
may want to push it to 'master' sooner to give it a larger
exposure. I dunno, and I do not want to decide this myself the
week before I'll go offline for a few weeks (i.e. today).
3. Then we would enlist help from folks who are more familiar with
Windows platform (like you) to see how the "run parallel workers
and collect from them" can be (re)done with a nice level of
abstraction. I am hoping that we can continue the tradition of
the evolution of run-command.c API (I am specifically impressed
by what you did for "async" that allows the callers not to worry
about threads and processes) aroundt this area. That is
obviously a mid- to longer term goal.
Thanks for working together well, you two.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html