bug-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Problems with multithreading and slow compilation


From: Laurence Finston
Subject: Problems with multithreading and slow compilation
Date: Wed, 07 Jul 2004 01:41:47 +0200
User-agent: IMHO/0.98.3+G (Webmail for Roxen)

Hello, 

I've been having a bit of trouble with the debugging output 
produced by Bison when `yydebug' is set to a non-zero value, 
when calling `yyparse()' multiple times in different threads.

Since the output is just written to `stdout' (or maybe `stderr'), 
the output from the different invocations of `yyparse()' is all
mixed up.  

I haven't examined the output closely enough to tell 
whether the actual calls to `printf()' (or whatever Bison uses) 
are interrupted, but I suspect they are.

Would the Bison developers have any interest in implementing 
the following features? 

1) making it possible to redirect the debugging output to files, 
   one for each invocation of `yyparse()'.

2) Protecting `stdout' and `stderr' with mutexes, to keep 
   writes to these streams from being interrupted
   (unless they are already, of course).
   

I'm also having problems with having to wait a long time while the 
C++ file generated by Bison compiles.  I've been meaning to try to put
more code for the actions into functions to see if this will help, 
but since the return values of the functions must be tested in the rules, 
it makes things more complicated and interferes with hacking.

What I'd like is a way of breaking up the actions for the rules into
multiple compilation units, so that only the parts that have changed
will need to be recompiled.  Is this something the Bison developers
might consider implementing?
   
Have other users been having similar problems?

Laurence Finston
GNU 3DLDF maintainer
http://www.gnu.org/software/3dldf   



reply via email to

[Prev in Thread] Current Thread [Next in Thread]