From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id BAA30799; Wed, 9 Apr 2003 01:11:06 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id BAA30786 for ; Wed, 9 Apr 2003 01:11:05 +0200 (MET DST) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from smtp3.cp.tin.it (vsmtp3.tin.it [212.216.176.223]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h38NB3X15842 for ; Wed, 9 Apr 2003 01:11:04 +0200 (MET DST) Received: from host26-40.pool212171.interbusiness.it (212.171.40.26) by smtp3.cp.tin.it (6.7.016) id 3E8D74020017A11F for caml-list@inria.fr; Wed, 9 Apr 2003 01:11:02 +0200 From: Stalkern 2 Reply-To: stalkern2@tin.it To: caml-list@inria.fr Subject: Re: [Caml-list] Ocamlex/ocamlyacc breakage? Date: Wed, 9 Apr 2003 01:20:56 +0200 User-Agent: KMail/1.5.1 References: <200304081239.13990.stalkern@tiscalinet.it> <200304081808.48574.stalkern2@tin.it> <20030408180339.B73157F4D@lobus.fungible.com> In-Reply-To: <20030408180339.B73157F4D@lobus.fungible.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304090120.56363.stalkern2@tin.it> X-Spam: no; 0.00; stalkern:01 caml-list:01 mutexes:01 stdout:01 fork:01 callbacks:01 threads:01 ernesto:01 gtk:01 reentrant:01 commands:97 unix:02 thread:02 module:03 btw:03 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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