yet more tfork() problems...

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

 Hi fellas!

 Want to hear another story about problems with mintlibs tfork()? Yes?
Here comes one:

 I wanted to write a program to read some data from stdin and perform some
action with it. Since this action may be delayed due to several reasons,
but I didn't want the main program to wait for this and didn't need any return
code, I choose to do the action async with tfork(). Guess what I was trying
to write? ;)

 So the main programs collects the data to a temporary file whose name is
globally declared and just "exit(tfork(blabla, 0))". The `blabla' routine
should just open the file again and do what I want it to do, maybe blocked,
maybe not, doesn't matter for the async thread.

 What happened first, is that I opened another file with `fopen(name, "a")'
to append the data to. It spuriously occured that there was complete trash
in this file. It looked like the file buffer was flushed even when there
wasn't anything in it. When I gave up buffered I/O but used open/write for
the file I wanted to append the data to, *this* one worked ok.

 But the next thing is that the thread crashed with memory violation when
trying to dereference a pointer pointing to zero. The only pointer left in
the code was the filepointer for reading the tmpfile, which I was quite sure
was opened correctly. It also didn't crash at any special position, sometimes
it managed to write more, sometimes less, sometimes it even completely
succeded (when there was very few data). But in 90% it crashed.

 After having spend several hours tracking this down and finding nothing, I
became suspicious about the main program directly exiting after the tfork,
and placed a `sleep(1)' at the beginning of the thread routine. Suddenly,
everything worked perfectly right!

 That's where I remembered that it's said that tfork() "may cause problems
with some library calls, notably malloc()". When looking at the library code,
I saw that the main program explicitly closes all streams when exiting, and
this probably also resets them to zero. This does mean nothing else than you
can't use buffered I/O streams in a tforked thread if you can't guarantee
that the child is going to exit *before* the main program, probably completely
wiping out the initial reason of you chosing an async thread. :-(

 In my case, the thread can explicitly wait until the parent has exited, but
for other problems, this may not work. Since working with file pointers seems
to be quite ok, although access to static structures is not guarded by any
kind of semaphore, I wondered if things might get better if one adds a `pid'
field to the structure holding the pid of the program which has opened the
stream, and only close those *we* explicitly own.

 Any ideas about that? To do it good, it would probably require some kind of
semaphore... And all this only because of the non-working vfork...

ciao,
TeSche
-- 
Torsten Scherer (TeSche, Schiller...)
Faculty of Technology, University of Bielefeld, Germany, Europe, Earth...
| Use any of "finger itschere@129.70.131.2-15" for adresses and more.|
| Last updated: 14. April 1994.|