[Caml-list] Ocamlex/ocamlyacc breakage?

[Caml-list] Ocamlex/ocamlyacc breakage?

[Stalkern 2]

Hello to everybody

I've connected a ocamlex/ocamlyacc parser to a graphical button; this parser 
parses a file. 

When I click on the button repeatedly and fast several times, the parser 
starts but it crashes. Failures happen at unrelated, apparently random 
positions, and strace shows unrelated, apparently random (in the range of 
open files) Unix.select errors before the parse_error. 

I have put Unix.lockf locks, but readers are not exclusive. So I thought to 
skip the whole reparsing in case a reading lock is already there, but the 
F_TEST (*Test a region for other process locks*) command is documented for 
use in Unix.lockf : file_descr -> lock_command -> int -> unit, that returns 
unit, so how could a TEST ever be possible?

Any hint? BTW the whole is in a program with threads and runs in a ocaml 
compiled with posix threads, but this part does not use threads. 

Thank you in advance for any advice

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

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

[Stalkern 2]

How is it possible that different instances of a ocamlyacc parser applied to a 
complete, closed file spoil each other's reading, but _when I fork the 
process and have the parent Unix.wait for the child_ everything gets OK?? 

The only solution springing to my mind is that ocamlyacc is not quite 
reentrant! 
What should I do then?

;-O

Ernesto


Il  Tuesday 08 April 2003 13:02, Stalkern 2 ha scritto:
> Hello to everybody
>
> I've connected a ocamlex/ocamlyacc parser to a graphical button; this
> parser parses a file.
>
> When I click on the button repeatedly and fast several times, the parser
> starts but it crashes. Failures happen at unrelated, apparently random
> positions, and strace shows unrelated, apparently random (in the range of
> open files) Unix.select errors before the parse_error.
>
> I have put Unix.lockf locks, but readers are not exclusive. So I thought to
> skip the whole reparsing in case a reading lock is already there, but the
> F_TEST (*Test a region for other process locks*) command is documented for
> use in Unix.lockf : file_descr -> lock_command -> int -> unit, that returns
> unit, so how could a TEST ever be possible?
>
> Any hint? BTW the whole is in a program with threads and runs in a ocaml
> compiled with posix threads, but this part does not use threads.
>
> Thank you in advance for any advice
>
> 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

-------------------
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

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

[Tim Freeman]

From: Stalkern 2 <stalkern2@tin.it>
>The only solution springing to my mind is that ocamlyacc is not quite 
>reentrant! 
>What should I do then?

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.

-- 
Tim Freeman                                                  tim@fungible.com
Which is worse: ignorance or apathy? Who knows? Who cares?
GPG public key fingerprint ECDF 46F8 3B80 BB9E 575D  7180 76DF FE00 34B1 5C78 

-------------------
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

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

[Stalkern 2]

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

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

[Jacques Garrigue]

From: Stalkern 2 <stalkern2@tin.it>
> 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. 

IIRC, you must be careful when using Unix.fork in a gtk program,
because the child thread will attempt to close the X connection on exit,
except if you use exec to start another command.

The natural way to do it is indeed to start independent threads for
readers. Glib.Io.add_watch is another option, if you just intend to
wait for input without blocking computations.

Jacques Garrigue

-------------------
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

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

[John Max Skaller]

AFAIK both ocamllex and yacc are reentrant.
Ocamlyacc preserves state on its stack in a functional
manner. Ocamllex preserves state in the lexbuf.

Maybe you are reusing the same lexbuf for two simultaneously
running parses?

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850


-------------------
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