Mail Archives: djgpp-workers/1999/02/18/03:09:04
On Wed, 17 Feb 1999, Alain Magloire wrote:
Just to cover a few tidbits that Richard Dawe didn't:
> - how about chroot () ? supported ?
There's no `chroot' in DJGPP's library. So, to support this
functionality, I'd suggest to override the library version of `chdir'
with a custom one that maintains the current root, prepends it to all
absolute file names, and disallows changing directory above the
current root. `chroot' will then just set an internal variable.
> - the infamous fork (). For example inetd on a busy
> day, with a good wind can for requests in 2 digits
> per second. Can djgpp fork()'s handle it.
DJGPP's `fork' simply fails every call. I suggest to replace it with
something which does "start /m inetd", together with some trickery to
implement inheritance of environment variables, file handles, and
other information that `fork' passes. "start" will only work on
Windows, but current options for sockets are only for Windows anyway.
Besides, running a Unix-style daemon on plain DOS would require either
a dedicated machine or a lot of TSR (that's Terminate-and-Stay-Resident)
tricks that are profoundly hard in DPMI mode. So limiting
high-throughput daemons to Windows doesn't seem as a grave limitation
to me. On DOS, you can always say that the max throughput is limited.
> O_NONBLOCKING
In general, non-blocking I/O is not supported. However, if you cannot
port inetutils without it, you could use the DJGPP Filesystem
Extension feature to redirect such I/O request to another program
(launched e.g. with a similar "start /m" trick), with some
synchronization means between them.
> exec (), signal ().
Both of these are supported. Hoever, note that signals cannot be
delivered between programs (e.g., you cannot kill the child program by
sending it SIGKILL), and delivery of signals is blocked while a
program is inside a DOS call. Since running a child program is done
via a DOS call, this means no signals until the child returns.
- Raw text -