www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1999/02/28/07:45:34

Date: Sun, 28 Feb 1999 14:43:58 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Alain Magloire <alainm AT rcsm DOT ece DOT mcgill DOT ca>
cc: djgpp-workers AT delorie DOT com
Subject: Re: inetutils
In-Reply-To: <199902262327.SAA11493@mccoy2.ECE.McGill.CA>
Message-ID: <Pine.SUN.3.91.990228144332.5950e-100000@is>
MIME-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com

On Fri, 26 Feb 1999, Alain Magloire wrote:

> I don't have POSIX.1g at end to see the rationale but it seems, to me,
> that spawning without being able to redirect the file descriptor
> of the child, restrict the utility of spawn().

There's probably some sort of misunderstanding here (at least on my
part ;-).

`spawn' *does* allow to redirect the standard handles of the child
program, it just requires that the parent redirects its handles for
that; the child then inherits those redirected handles.  Since the
parent doesn't resume until the child exits, it doesn't need to worry
about its standard handles during the time the child program runs.
When the child does return, the parent simply restores its handles to
previous values.

`dup' and `dup2' *do* work in DJGPP, exactly like you'd expect.

> So in other words, you're saying, it is not possible to port
> the inetutils servers, that rely on the operating system to provide
> some sort of multitasking via the system calls(fork/spwan,...).
> However it is possible to do it on Windows but not with djgpp framework ?

Since the multitasking is provided by Windows (which *can* be called
an operating systerm ;-), it is exactly like on Unix, except that the
way I described to run programs asynchronously doesn't include
inheritance of standard handles and environment variables, so these
must be treated separately and specially (in this case only).

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019