EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: [Merge] lp:~ralph-lange/epics-base/thread-hooks into lp:epics-base
From: Ralph Lange <[email protected]>
To: Andrew Johnson <[email protected]>
Date: Tue, 03 Jul 2012 08:54:20 -0000
Hi Andrew,

> The name 'epicsShowThreadInfo' implies this routine is part of the epicsShow
> subsystem.  The original name 'showThreadInfo' was static and thus only used
> internally to the posix implementation, but if you're making it visible I
> think it needs to match the other epicsThread... names.  Maybe name it
> epicsThreadShowPrivate(), which matches the Win32 implementation (although
> there the routine is static).

Will do.
On a closely related issue, I am quite unhappy with the confusing names of the public API functions

epicsThreadPrivateCreate
epicsThreadPrivateDelete
epicsThreadPrivateSet
epicsThreadPrivateGet

that are - unlike the other funtions that contain "Private" - *not* private, but public functions.
Also, they implement what is more commonly called "thread local storage".
Do you think it would be worthwhile renaming them to *Local* and deprecate the existing names, adding macros to continue supporting them?!

> If you don't intend that routine to be called by user code the declaration for
> it doesn't have to appear in any header files either, it could just appear in
> the posix/osdThread.c file where it's used.

True. Will do.

> I would also prefer that it take
> an epicsThreadId argument instead of the epicsThreadOSD* pointer; that should
> remain for internal use only (epicsThread.h has a typedef making the two
> identical).

If (after the mentioned change) the function is private, not in any header file, and any implementation would have to cast the argument to an epicsThreadOSD* pointer anyway, I don't see the point in using the opaque type.

~Ralph

-- 
https://code.launchpad.net/~ralph-lange/epics-base/thread-hooks/+merge/112806
Your team EPICS Core Developers is requested to review the proposed merge of lp:~ralph-lange/epics-base/thread-hooks into lp:epics-base.


References:
Re: [Merge] lp:~ralph-lange/epics-base/thread-hooks into lp:epics-base Andrew Johnson

Navigate by Date:
Prev: Re: [Merge] lp:~ralph-lange/epics-base/thread-hooks into lp:epics-base Andrew Johnson
Next: Re: [Merge] lp:~ralph-lange/epics-base/thread-hooks into lp:epics-base Ralph Lange
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: [Merge] lp:~ralph-lange/epics-base/thread-hooks into lp:epics-base Andrew Johnson
Next: Re: [Merge] lp:~ralph-lange/epics-base/thread-hooks into lp:epics-base Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 26 Nov 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·