dsimcha wrote: > == Quote from downs ([email protected])'s article >> dsimcha wrote: >>> == Quote from downs ([email protected])'s article >>>> I submitted a patch a while back for constant-time removeRange. Can we >>>> dredge >>> that one up and/or implement something similar? It's rather useful for >>> things like >>> stackthreads that need to add and remove lots of ranges :) >>>> (Search the NG for "Feature req.+Patch: O(1) removeRange") >>> I guess removeRange is currently O(N)? I haven't looked. Anyhow, I think >>> the >>> bigger problem in practice, i.e. until N is unrealistically large, is that >>> removeRange requires taking a lock. O(1) would be nice, though. >>> >>> What does StackThreads (I assume this is equivalent to fibers) do that it >>> requires >>> so many add/remove ranges? >> The virtual stacks I use are being allocated via mmap. Every stack is a >> range. > With every context switch, the relevant ranges need to be modified - the range > that is being switched to needs to be removed (because it becomes the "main" > stack > which has special GC handling), and the stack range that's being switched from > needs to be added. > > IDK, that sounds a bit expensive even with O(1) removeRange. Are you using > some > home-grown impl. of StackThreads/fibers, Tango's, or D2 druntime's? If it's > Tango's or druntime's, I haven't looked, but I would think the GC understands > stuff about them. If it's your own, have you considered switching and maybe > submitting whatever extra features your impl. has to Tango and/or druntime?
Well .... D1 Phobos :) I have some philosophical disagreements with the Tango project, much as I admit their technical superiority, and D2 is still too beta. But at least I don't use tools.stackthreads that much these days, so it's fine :)
