On 12/13/2012 12:40 AM, Panu Matilainen wrote: > 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. I'm trying to point out that all of the data that seems to be logically necessary can be ["re-"]computed by the parent without communicating with the child, with the exception of the Success/Fail code which only the child can determine, but which can be returned from child exit() to parent waitpid(). This data which the parent can compute for itself explicitly includes headers, file objects, and so forth. Certainly the headers can be read and decoded in parallel with whatever the child is doing. New open file descriptors might have to wait until the child finishes before the parent can access those files. I'm suggesting that there may be another solution or partial solution that has not been considered enough so far, and that costs associated ith this approach (particularly in development time) may be less than typical IPC. Consider flex-2.5.36-1.fc18.x86_64.rpm, to pick one small example. Various options to "rpm -qX -p flex*.rpm" ought to list everything that the parent needs to know. I believe that the parent can compute all of that for itself, relying on the child only for the Success/Fail code to confirm whether instantiated reality agrees with theory. If there is something that the parent must know that "rpm -q" cannot provide, then an explicit example from installing flex*.rpm would illuminate a significant aspect of the problem. -- _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
