Date:	Thu, 18 Mar 93 09:15:36 +0100
From:	Divisione SINCON <sincon AT minsky DOT csata DOT it>
Subject:	go32v2
Apparently-To:	djgpp AT sun DOT soe DOT clarkson DOT edu

Hi,
   since we speak about enhancing go32, this is, perhaps, the right moment
to rise the multithread issue.

I know quite well that MS-DOS is neither multi-thread, neither reentrant.
Most of Unix programs, on the other hand, rely quite heavyly on pipe(2)
and [v]fork(2).
In most cases real concurrency is not required, but they use the multi-task
primitives all the same, essentially to spawn a series of filters.
I'm speaking specifically about groff and cvs, the first uses fork(), the
latter pipe().
I'm trying to port both of them under djgpp (major problem is time).
Instead of rewriting the portion of code that uses these primitives, getting
far from the original code, i decided to implement them.
Of course the implementation is not a real multithread, since the parent waits
for the child to complete (or the reverse, if appropriate), but it's adequate
for the intended use.
Right now i have a working version of pipe(2) and a somewhat working version
of vfork(2); the latter is a real kludge using setjmp/longjmp.
In the process of writing this i had to modify go32 to support spawn(), which
is another 'good thing' since it allows porting of 'make' and all other
programs that need to know the return status of the child.
This work is available to whoever wants it, of course.
The real matter is that the main problem with the vfork() package is (almost)
not multi-processing related, but file-descriptor related!.
When the vfork() is used to spawn a series of piped-together programs (as groff
does) every child redirects it's own stdin/stdout, CLOSING the previous one!
Since in go32 the selection of file descriptors is handled by TurboC, it is
global, with no way to interfere.
To make a long story short (i will elaborate on request), i had to modify the
sources in order to make it work.
While a complete support for multithread is surely beyond the scope of any
go32 release, i hint at the possibilty that a limited version could be
supported, which would ease many portings.
The other thing that gets messed up in portings is signal(2) and related.

Any comments ?

I stop here so the wish-list is't all that long...

Best Regards
Mauro Condarelli
sincon AT minsky DOT csata DOT it

- Raw text -