libdpkg: m_fork and friends
Hi all,
I've already started this thread on debian-win32, however I've moved it
here as my questions are about proposed solutions to os-specific issues.
I've started trying to port dpkg natively to Windows (as opposed to
using Cygwin).
One area that may cause problems is that Windows doesn't have fork
functionality, so implementing m_fork() will be challenging.
From what I've seen so far, the only time m_fork gets used in the dpkg
source is as part of the process of spawning a child to do some work,
and writing Win32 child-spawning code should be pretty simple.
It was suggested on debian-win32 that I could use GLib for the process
spawning. This would simplify code, as there are functions to spawn
synchronously or asynchronously, and using single-string or vector-based
arguments, as well as automatically creating pipes for
stdin/stdout/stderr. On the down side, it does mean introducing a new
dependency to dpkg.
Either GLib or Win32-specific code will can solve the process spawning
issue, and this is all well and good as long as no other packages are
using the m_fork (and possibly m_pipe/m_dup2) code. So my questions are:
- Are other packages supposed to use m_fork, m_pipe, etc?
- If not, do we know of/care about packages that do use it?
- If so, would breaking API compatability to allow a Win32 port be a
problem.
Please note that my last question is badly phrased... it would _only_ be
the Win32 port that would have a changed API, specifically the functions
that can't be (easily) implemented (m_fork, possibly m_pipe/m_dup2)
would be #ifdef'd out, or moved to a separate file that autotools links
in on non-Win32 platforms.
Thanks,
Phil
Reply to: