Am Wed, 11 Dec 2013 11:04:29 +0100 schrieb "Gianni Pisetta" <[email protected]>:
> On Wednesday, 11 December 2013 at 08:54:18 UTC, Marco Leise wrote: > > Am Wed, 11 Dec 2013 09:10:09 +0100 > > schrieb "Gianni Pisetta" <[email protected]>: > > > >> 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? > > I also like the managed stack idea, but i think the main problem > with that is that it is harder to understand what's going on when > you have to debug. > I'm not at the point yet of passing the results to the main > thread, but i think at the end i will make the entire tree > immutable(or maybe already create it with immutable) and add the > reference to a shared array or use a message passing pattern like > the one in std.concurrency. > > Gianni Pisetta Then wait a second! fork() creates a new _process_, not a thread. The two options I gave are pretty much the only ones available for communication between local processes. Maybe add a TCP socket connection to that... Shared arrays and std.concurrency work only for _threads_ inside the same process. -- Marco
