> On 21 Dec 2018, at 10:22, Hans Åberg <haber...@telia.com> wrote: > >> On 21 Dec 2018, at 10:00, Uxio Prego <uxio.pr...@gmail.com> wrote: >> >>> A threaded parser aside, I found threading difficult to debug in general, >>> so good with a way to turn it off. >> >> Not sure what do you mean. Threaded parser to me sounds like a *.y >> source code doc where threads are spawned and joined in the inner >> code blocks of grammar rules. > > You snipped the part I replied to: > >> - On performance or multithreading problems while in >> Yacc mode: >> 1. Proxy all parsing needs in a single thread and >> queue parsing requests. > > I am not sure what you mean here. I looks like you want to make a threaded > parser, which I haven't tried.
My whole message was horrible, mixing Yacc parsing and _contemporary_ Bison 2.3 parsing and contemporary Bison 3 parsing in not the clearest way. Written in another way: 0. Consider a Yacc parser as a way to have a well documented common ground for Bison 2 and potential future releases of Bison departing from Bison 2 but not departing from Yacc compatibility - simply my own guess on the Bison roadmap, which I don't know, so I might be much wrong. I'm thinking that one can depart from Bison 2 much easier than from Yacc, as there are a lot more printed documentation (and non printed too) about Yacc than about Bison 2. 1. Once hit a multithreading problem (e.g. two threads are potentially wanting to parse some doc or string at a same time using the non reentrant but Yacc compatible Bison parser) proxy all parsing needs in a single thread, in order to avoid invalid access to the Yacc compatibility mode static globals. 2. After applying (1.) and once hit a performance issue (i.e. at some point or under certain circumstances one thread is not enough to handle all the parsing needs), convert the Yacc compatible parser in a Bison 2.3 pure parser, if `master` Bison is still compatible with Bison 2. Else convert the Yacc compatible parser in a `master` Bison pure parser, and then demand installs of the software on macOS to upgrade to contemporary Bison, ideally leaving the user the choice between a standalone Bison install, a Macports install, a Homebrew install, docker strategies, etc., unless in order to handle the rest of dependencies of the software using Bison, it strongly encourages one or several of these choices over the other choices. Fortunately I can't think of any case where I could want to spawn or join threads inside inner C blocks of grammar rules. Anyway I suppose one can do this, specially if one such thread is joined in the same inner C block which spawned it. _______________________________________________ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
