I can change the macro/function name and its implementation easily enough, that's not a problem. This, though: >All that said, every time I see people patching USE_THREADS code I >wonder if it's all going to be for nothing. I don't see much hope >for salvaging the existing model of USE_THREADS where prolific >locking is needed. Can we get a ruling on whether threads as they stand are in or out? And a statement of direction if they're in? I really don't mind writing code that ultimately gets tossed out because it sucks or there's a better way to do things--it's a learning experience if nothing else, and the next time around the code's usually better. What I don't want to bother doing is writing code that is going to be tossed because I'm going the wrong way. I mean, at this point I've got code for Thread::Stop roughed out, preliminary mutex tracking set, and a scheme to make unsynchronized scalar access safe with about an order of magnitude less overhead than my last try. Getting them all going is a good chunk of work, and I don't mind doing it. I think it needs to be done, and that's not the point. I have other things to occupy my time, though, and I'd just as soon not tilt at these windmills without cause. If the current threading model is dead, can we just shoot the poor thing and be done with it? Otherwise let's commit to it and figure out what needs to be done. This limbo state isn't doing anyone any good. Dan ----------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@sidhe.org have teddy bears and even teddy bears get drunkThread Previous | Thread Next