(another) problem with mntlib41 tfork() function

[Torsten Scherer <itschere@TechFak.Uni-Bielefeld.DE>]

Hi!

 It was quite often mentioned that the mintlibs tfork() function shouldn't
be regarded as anything more than a hack until MiNT gets a real vfork() call,
so I know I should use it with caution, but today I've strumbled into a
really severe problem when writing a multi-threaded smtp sendmail clone.

 It goes like this: Each time a thread is started, memory is allocated from
the calling process via pexec(5) to create a new basepage. Since this base-
page isn't immediately started, the memory seems to be assigned to the
calling process. This one of course forgets the adress of the threads basepage
as soon as the tfork() call is left.

 So the thread comes up, works a bit and goes down again, leaving the basepage
memory assigned to the caller, who doesn't know about this and therefore won't
free it. To be more precicly: Each thread costs me 16K (memprot) which are lost
forever.

 In general its possible to get a process' basepage by an ioctl on the procfs,
but this can't be done when pwait3() reports the termination, cause the file
is already removed then. So the only way to get the basepage is to ioctl
directly after the tfork(), before the pwait3() and probably better before
the child terminates.

 This sounds difficult and like a waste of code but was my only idea. Pity,
it doesn't work correctly for very long. I guess the error is something like
your Mfree() call doesn't really frees the memory cause some other child
shares it and therefore it's lost again. This may not disturb you if you just
want to start one or two threads, but if you want to start several dozen of
them spreaded over the time the computer is running, I swear this drives you
wild and/or crazy.

 The question now: When will MiNT get a real vfork?

 Hmm, or better something quick: Does the "create basepage" call already
assigns a new pid to the basepage, or is it assigned later, when the basepage
is run? Mightn't it be a good idea to perhaps add some Pexec() mode which does
the same as the thread code from the library, but really assigns all child
memory to the child, so Pterm() can free it?

 But I feel something like there isn't something like real child memory, so
all memory the child may at any time allocate, is also shared by its parent.
I wouldn't like this, but I wonder if that's the reason...

 Any ideas?

it's just me again, being curious...
TeSche