can clone a thread?

[Marco Leise]

Am Wed, 11 Dec 2013 11:04:29 +0100
schrieb "Gianni Pisetta" <pisetta.gianni at alice.it>:

> 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" <pisetta.gianni at 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?
> 
> 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