It might help to build on your idea. As you note, there are no global mutated values, and that means Marpa is thread-safe, in the sense if you are running several completely independent instances of Marpa at once, there will no problem -- the only data they share is constant.
However, if you, for example, create two recces from the same base grammar, both recces will share non-constant data in the grammar. (There's no logical necessity for this sharing, I just found it convenient.) So, from the point of view of the two recce's the data in the base grammar is "global". That is, as you checked (thank you for making sure, by the way!) multiple Marpa instances won't share executable-wide non-constant globals. But two recognizers *will* share what from their point of view are non-constant "globals" in their shared grammar. And between these 2 recognizers, all the same issues arise that would arise between two Marpa instances that were sharing non-constant program wide data. The use of shared values in the grammar is not aggressive, but memory coherence issues make any sharing of non-constant data between threads dangerous. So this is why Marpa *is* thread-safe for multiple Marpa instances, but is *not* thread safe for multiple recognizers (or other derived objects) based on the same grammar. I hope this helps, jeffrey On Sun, Dec 7, 2014 at 11:04 AM, Vaše jméno <[email protected]> wrote: > jeffreykegler, sorry to come up with the threading thing again, but > anyway: It's sure not an obstacle for libmarpa use. Im not looking to > paralellize my parser either, i dont need to create multiple grammars, im > planning to use a standalone process. > > I think, tho, it would be the simplest pattern of integrating libmarpa. > First i had everything working in my apps main thread. Now that i realized > parsing takes time, the simplest change would be to keep the code that sets > the grammar up in the main thread, and do precompute and parse in another > thread. > > It seems easier to just avoid touching the grammar from the main thread > once the parsing thread is running, instead of creating a "special marpa > thread", keeping it around, telling it to call my grammar defining > function, then telling it to parse.. > > What doesnt let me drop this topic is that you have, again, not given a > technical explanation, and i feel theres something i dont understand that i > should:) > > The fact that time objects use their base grammar doesnt explain it in any > way. Nor does the theory of atomicity touch upon, in any way, the > sequential use in multiple threads. > > I tried a few greps on marpa.w, and all i could conclude was that i didnt > see any funcion-local static variables. Am i loosing my c-skills? Is the > reason in other libraries? > > In that you want to have the freedom to change this in future? > Just curious. > > -- > You received this message because you are subscribed to the Google Groups > "marpa parser" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "marpa parser" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
