can clone a thread?

[Gianni Pisetta]

> D is cross-platform, so to have a wrapper for fork() would
> mean to get it working on Windows, too.
> std.process, can must use fork() of course, since it is the
> way to spawn a child process on Posix systems. fork() doesn't
> clone a thread, but a whole process. So there is no issue
> with the GC, as it will be cloned as well. Until Posix threads
> were introduced, it was common to create "threads" using
> fork(), so it probably works ok for you. Maybe we can find a
> better solution though if you tell us some more.
>
> For example this exists in D:
>
> static this()
> {
>   // Initialize TLS variables
> }
>
> That is a module constructor that is run once for each new
> Thread. You could prepare your TLS variables there as a copy
> of global data or other function calls.
> If you really need an automated copy of all TLS variables for
> a new thread the situation looks dim I guess :p

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.