[concurrency-interest] Soliciting input about removeAllThread Locals

Patrick Moore pmoore@brocade.com
Mon, 9 Dec 2002 10:51:03 -0800


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C29FB3.EC97F820
Content-Type: text/plain

DON'T put this method in -- PLEASE!

To me it seems like removeAllThreadLocals is a shotgun approach to a rather
narrow problem. (And like most it seems that the consequences are messy and
never ending)

This could be buried deep in some innocent sounding method by a junior
programmer that would cause destructive consequences far and wide. What
happens if the method is in a method that is call both by Executor based
methods and by the main thread. How are you going to stop abuse? As an
architect how can I guarentee that no 3rd party code I am using is using it
properly? I now have to abandon ThreadLocal's because I cannot rely on them
being set correctly.

On a lesser note - One of the things I have not seen discussed that to me
seems rather useful. The ability for Executor  implementations to associate
information about the thread using ThreadLocals. Also may be a debugger
wants to track which Callables/Runnables ended up using which threads. This
might be useful for discovering performance problems. 


-Patrick Moore

------_=_NextPart_001_01C29FB3.EC97F820
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [concurrency-interest] Soliciting input about =
removeAllThreadLocals</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>DON'T put this method in -- PLEASE!</FONT>
</P>

<P><FONT SIZE=3D2>To me it seems like removeAllThreadLocals is a =
shotgun approach to a rather narrow problem. (And like most it seems =
that the consequences are messy and never ending)</FONT></P>

<P><FONT SIZE=3D2>This could be buried deep in some innocent sounding =
method by a junior programmer that would cause destructive consequences =
far and wide. What happens if the method is in a method that is call =
both by Executor based methods and by the main thread. How are you =
going to stop abuse? As an architect how can I guarentee that no 3rd =
party code I am using is using it properly? I now have to abandon =
ThreadLocal's because I cannot rely on them being set =
correctly.</FONT></P>

<P><FONT SIZE=3D2>On a lesser note - One of the things I have not seen =
discussed that to me seems rather useful. The ability for =
Executor&nbsp; implementations to associate information about the =
thread using ThreadLocals. Also may be a debugger wants to track which =
Callables/Runnables ended up using which threads. This might be useful =
for discovering performance problems. </FONT></P>
<BR>

<P><FONT SIZE=3D2>-Patrick Moore</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C29FB3.EC97F820--