Check out core.thread.Fiber. No fiber-local storage yet, but it's something I've considered and seems relatively important for writing a correct D program with fibers.
Sent from my iPhone On Sep 28, 2011, at 2:03 AM, Chris Dew <[email protected]> wrote: > Warning: I've written multi-threaded code in C, Haskell and Java, but > only single threaded code in D. > > I'll use the word 'fibre' for a job which may take some time to run, > and may be blocked from time to time. It may mean the same as 'task' > in D, but I'm not sure. Greenlets, lightweightthreads or possibly > cooroutines may be other names which have some bearing here. > > In order to run N fibers efficiently I'm making a big assumption that > we need to map them to a pool of M threads, where M is ~= NumCores (+ > num blocked threads?) and then use some form of 'select' or 'epoll' in > the runtime to swap them in and out of threads, when they are really > to run again. > > What I think I want is fibre local storage, by default. Thread local > storage by default sounds fine for low-level work, but I don't want to > think about, or manually implement, how my fibres are mapped onto > threads efficiently. > > As fibres can be moved between threads by the runtime, does that mean > that their storage must be 'shared', with all the inefficiency that > brings? > > Are there Uniqueness Types in D? They could be used to move the > fibre's storage between threads as the fibre moves, without > compromising safety. > > If not, how do you currently implement storage for a fibre (task?), to > make it migrateable when the runtime moves the fibre between threads? > > Thanks, > > Chris.
