[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.



Reply to: