Re: What you get is what you want

> I am agree with you

We say 'I agree with you'


> But, the fact is that using ThreadLocal is more 
> slow than a downcast.  Because blocking_enqueue is a 
> performance-critical operation, I prefer using a downcast.

Granted, threadlocals are about 10 times slower but every other 3rd party code cannot exploit the
currentThread cast, hence must resort to ThreadLocal anyway in order to decorate the thread
instance.
To me, that is a very limited improvement to justify currentThread.


> Sandstorm is already responsible to create and manage all threads, thus 
> it don't seems a bad design solution.

False: the TM is responsible for creating/managing threads instances. And it should be pluggable.
We should be able to create any thread class, not just SandstormThread.

And a stage or a queue should only expect an API, not classes, to be provided in its environment.
At best, the thread class should implements an interface, so that you would use

((ISandstormThread)Thread.currentThread()).setBlocked(+/-)




		
__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com 
 



-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8