Am Wed, 11 Dec 2013 09:10:09 +0100 schrieb "Gianni Pisetta" <pisetta.gia...@alice.it>:
> No, i think fork or something similar is the way i prefer to go. > I'm working on a simple top-down parser, so i save all the data > references in the context of the function and at the end of it i > create the syntax tree object with all his childrens. So i have > the already allocated objects in the tls and the info on the > realtionships of these objects plus the parser state in the call > stack. I want to duplicate the parser because i want all the > possible syntax trees as a result and when the tokenizer will > find in the input two or more possible tokens, it must fork and > return for each thread one token from the possible ones. At the > end if one or more threads made to the end, each thread copy his > syntax tree on a shared array and the main thread then can work > on the results. > > Another way to solve this is to move all the info from the call > stack to a stack managed by me, have a standard procedure that > fills the stack. When i must duplicate the thread i can create a > new one, make a deep copy of the objects in the stack and the > stack itself, then call the standard procedure again. But i think > this is a bottom-up parser and a major change in the application > design. > > For now i will stick with fork, if in the future a similar > function is implemented in core.thread, i will use it. Alright, fork is optimized for this kind of stuff and it should work fine. Personally I would likely have tried a manged stack instead of cloning the whole application. How do you write back the results from the child processes? Do you use pipes or shared memory? -- Marco