Re: libdpkg: m_fork and friends
On Mon, Mar 19, 2012 at 3:11 PM, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
> lkcl luke writes ("Re: libdpkg: m_fork and friends"):
>> um... is there any chance of redesigning dpkg to not require fork?
>> popen looks like it could be used in movecontrolfiles; likewise in
>> extracthalf.
>
> dpkg was never intended to be portable to not-at-all-unix-like
> systems. I'm afraid you are probably onto a loser.
i'm really tempted to take that as a challenge just to prove it can
be done, but equally i fear you may be right. yuck.
>> ok, i'm labouring the point: is there any situation in dpkg where
>> fork *isn't* used to do the same job as popen?
>
> You mean, does it fork and then continue in both child and parent
> without calling exec ? I don't think there are any irremoveable cases
> of this but any removeable cases will probably involve intrusive
> patches.
ok, allow me to go through them formally [patience appreciated]
> Also note that dpkg depends fundamentally on traditional unix
> filesystem semantics, which are not generally available on Windows
> (and if anything resembling them is, the performance is very poor).
yeahhh that's fine. performance is never a major issue here :) but
i believe, last time i looked, all the dependencies had been sorted
out (with one exception) by the mingw, msys and git-win32 teams. i
had to track down an implementation of flock but that was about it.
if git, bash and ssh can all be compiled for win32 using mingw32 i'm
sure that dpkg shouldn't be that hard.
anyway. review. this is based on dpkg-1.16.1.2 (notes below) - it
all looks good. the only two i have any queries about are fd_fd_copy
and the loggers.
loggers: although statusfd_add records the pipe's fd, there's no call
to subproc_wait (the pid is thrown away). fd_fd_copy: not sure what
this is actually for: perhaps a simple exec of the "cat" command would
do?
other than those two queries (one of which may have highlighted a bug
- not calling subproc_wait) i'd say it was doable.
the really bigger issue is, as someone earlier highlighted (with the
cygwin thing): some programs still hang on to their DLLs until they're
well and truly killed. however, i'd say (perhaps naively?) that that
was for the postinit and prerm (etc.) scripts to resolve and start
knocking processes on the head. my main curiosity is to see if dpkg
can be press-ganged into service (any service), and worry about those
kinds of issues later on down the line :)
l.
build.c
--------
do_build: line 451. pipe created to tar. wait @ 482
do_build: line 475. compress filter called. wait @ 481
do_build: line 531. pine to tar. wait @ 585
do_build: line 543. compress filter. wait @ 584.
do_build: line 554. find called. wait @ 576.
extract.c
---------
movecotnrolfiles: line 59. command shell. wait @ 63
extracthalf: line 263. fd_fd_copy. wait @ 325.
extracthalf: line 280. decompress. wait @ 323.
extracthalf: line 292. tar. wait @ 320
the purpose of the fd_fd_copy isn't clear to me (as in, i'm not sure
it's needed at all).
split.c
--------
deb_field: line 61. exec to backend. wait @ 81.
archives.c
----------
archivefiles: line 1238. exec to find. wait @ 1274
help.c
-------
do_script: line 270. exec script. wait @ 282.
ensure_pathname_nonexisting: 618. exec rm. wait @ 624
main.c
------
run_status_loggers: line 456. hook command. *no wait*.
processarc.c
------------
deb_reassemble: line 95. execlp splitter. wait @ 101.
deb_verify: line 135. execl verify. wait @ 145.
process_archive: line 428. execlp backend. wait @ 435.
process_archive: line 835. execlp backend. wait @ 862.
Reply to: