On 12/13/2012 12:48 AM, John Reiser wrote:
On 12/10/2012 11:22 PM, Panu Matilainen wrote:
Of course it should be technically possible to have rpm itself fork the transaction to separate process too, and it's something I've occasionally thought of doing to insulate the transaction execution from things like "oops closed the wrong terminal".
But it's not exactly a matter of "just add a fork() + waitpid()", there's a fair amount of state that would need to be somehow transferred between the processes. Also some API users, notably yum, *expect* the chroots to occur and would need changes to accommodate such a thing.
Is there an explicit literal example of this "fair amount of state"
that needs to be transferred from the child to the parent
for some particular actual package in Fedora 18?
waitpid() is a channel for 7 bits. The customary usage is Success [0]
or a Failure code (sometimes an enum, sometimes a bitmask, ...)
The parent already knows which .rpm, and thus can enumerate easily
the Provides and the Files (etc.) without invoking any scripts or reading
any pipes, and perhaps even before calling waitpid() [thus parallel
processing: both parent and child running at the same time.]
What more does the parent need to know, and is entitled to know?
7 bits? Get real.
Just to name a few things from top of my head, librpm needs to be able
to return headers, file- and problem objects, other callback data and
bunch of other transaction element related data / states to the parent
process.
Unless you're planning on providing patches towards this goal, I'm not
bother spend the day spelling out details just to satisfy your curiosity.
- Panu -
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
