Re: [Caml-list] Ocamlex/ocamlyacc breakage?

[Stalkern 2 <stalkern2@tin.it>]

Il  Tuesday 08 April 2003 20:02, Tim Freeman ha scritto:
> Use mutexes, perhaps.
>
> The functions in the Parsing module don't take parameters that
> indicate which parse you're working with, so I wouldn't be at all
> surprised if parsing is not reentrant.


Thank you Tim. 
I've tried out just to read and print the result, without parsing anything.
If I just start a bunch of readers, 
	GTK and stdout freeze;  
if I have Unix.fork parents wait for Unix.fork reading children, 
	readers show that they can't read everything to the end but stop at random 
points, 
	and only GTK drawing areas connected to expose events freeze. 

In a way, it looks like callbacks from a "imperative/stiff" GTK button stings 
the program, breaking the integrity of the whole "functional/elastic" 
program. I wonder what is the way to control this interaction and queue up 
callbacks execution without opening severe breaches like incomplete reading. 
BTW how it comes that GTK areas exposure is broken by a Unix.wait in another 
part of the program? Shall I set an independent thread for the area 
interested by the Unix.wait?

I am getting mad with this. I'd like to have a "central square" that commands 
start from and to which results come back only when they are over and done. 
I'll try to set up a thread more for file parsing, but I need to understand 
how to set up two-ways (request-reply) channels between threads (IIRC, so far 
I've seen only one-way channels).

Thanks again. I'll go on making more trials.
Ernesto

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners