Re: [bug-3dldf] Run errors

[Laurence Finston]

 Hi Glen,

> 3. Let me know whether `<filename>.mp' is generated properly and contains a
> `draw' command, and whether the same error with 
> `pthread_mutex_destroy()' occurs.  If it does, turn debugging output on in
> `Scan_Parse::output_func()' and Scan_Parse::output_command_func()', run 
> the program again, and send me a transcript of the terminal output.

The reason I say this is because I think the thread that does the output may
not be running at all, or not completing, on your system.   The thread that
does the parsing spawns it and is supposed to wait for it before terminating. 
 Then the main thread is supposed to wait for all of the parser threads.  In
the gdb output, it said a new thread was a "zombie".  I think this might mean
that it was detached, but it shouldn't have been.  I believe I originally
created such threads detached, but I think I changed this.  I'll check this.

I think it would be worthwhile to turn on debugging output in 
`~Mutex_Type()' in order to see whether the locking and unlocking really
succeeds.

If the thread for outputting the `Picture' locks the mutex after
`~Mutex_Type()' unlocks it, but before it calls `pthread_mutex_destroy()',
that could be the cause of the problem.   I think it would be a good idea to
call `sleep()' with an argument of 1 or 2 in `~Mutex_Type()' 
to give the other thread a chance to run.  
This would just be thread-inertia, though, and not a solution.  
But it would indicate clearly that this is the problem.  If `sleep(10)'
doesn't do the trick, then I would suspect that the other thread may be
blocking for some reason.    

Laurence

%% Local Variables:
%% mode:auto-fill
%% fill-column:59
%% End: