I am writing a daemon that parses an ini file and goes about its business.  In C++ I create a thread that does an inotify on the ini file and when it changes, it locks the associative array that contains the parsed ini file, reparses it and then does an unlock and goes back to waiting for the ini file to change again.  If the daemon needs ini data, it too participates in the lock and will wait until the new ini data is ready.

Problem 1 is defining the thread variable as a member of my ini class.  Since I have to use the auto t = thread(&parser), I can't figure out what type to make t in the class.  auto is no good without a rhs to give it meaning.  I tried Task and task, but got compiler complaints.

Problem 2 is the std.parallelism.Task is a struct and if I read correctly, structs are built on the stack and not the heap.  Once I've exited the function that creates the thread, does it go out of scope?  I want the thread variable to be a member of a class, so it will live on but maybe the thread will become extinct even if the variable lives on.  If I could get it to compile, I could answer this question with experimentation.

Problem 3 is there is some mention of memory in a parallelism task being for exclusive use by the task.  My intent is to lock/unlock the Associative Array while it is being accessed.  And that AA is a member of a class.  Would operating on a shared class member break the paradigm of std.parallelism?

In C++ I used the thread() method and so long as the member function it started was static, I got along pretty well.  Is this the wrong approach?

RC

"Robbin"  wrote in message news:yykhtfrfflbxdkukajoa@forum.dlang.org...

Hi Robbin,

> Problem 1 is defining the thread variable as a member of my ini class. Since I have to use the auto t = thread(&parser), I can't figure out what type to make t in the class.  auto is no good without a rhs to give it meaning.  I tried Task and task, but got compiler complaints.

You can declare variables using typeof(exp) as the type:
typeof(thread(&parser)) t;

> Problem 2 is the std.parallelism.Task is a struct and if I read correctly, structs are built on the stack and not the heap.  Once I've exited the function that creates the thread, does it go out of scope?  I want the thread variable to be a member of a class, so it will live on but maybe the thread will become extinct even if the variable lives on.  If I could get it to compile, I could answer this question with experimentation.

You can make the task a member of a class, which will be allocated on the heap.

> Problem 3 is there is some mention of memory in a parallelism task being for exclusive use by the task.  My intent is to lock/unlock the Associative Array while it is being accessed.  And that AA is a member of a class.  Would operating on a shared class member break the paradigm of std.parallelism?

You might find that it's easier to do this with message passing/std.concurrency, or use classic threading and locks from core.thread and core.sync.  I don't think your use-case is what std.parallelism was designed for. 

Thank you,  core.thread was exactly what I would have started with if I'd just seen the derived line in the example.  My earlier careless reading led me to believe I needed to compose my own class, which felt more complicated than it should be.