Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Mon, 02 Jul 2012 21:30:26 -0000

Sorry, a few more, although they're minor.

Please don't mark new API routines with epicsShareAPI; I'm trying to phase that out since almost nobody needs to use Pascal calling conventions on Windows any more.  It's really only needed for routines that may be called by Visual Basic (if there are any users of that left), so it may still be necessary on CA API routines but not really on most others.

This may be more of a discussion point.  Here's my output from epicsThreadShowAll:

epics> epicsThreadShowAll
            NAME     EPICS ID   LWP ID   OSIPRI  OSSPRI  STATE
          _main_    0x10b1060        0      0       0       OK
          errlog    0x113c830    20849     10       0       OK
          taskwd    0x113cc80    20850     10       0       OK
      timerQueue    0x113d5e0    20851     70       0       OK
           cbLow    0x113d8c0    20852     59       0       OK
        cbMedium    0x113db90    20853     64       0       OK
          cbHigh    0x113de60    20854     71       0       OK
        dbCaLink    0x113e300    20855     50       0       OK
        scanOnce    0x113ea10    20856     70       0       OK
         scan-10    0x114d670    20857     60       0       OK
          scan-5    0x114d8b0    20858     61       0       OK
          scan-2    0x114daf0    20859     62       0       OK
          scan-1    0x114dd30    20860     63       0       OK
        scan-0.5    0x114df70    20861     64       0       OK
        scan-0.2    0x114e1b0    20862     65       0       OK
        scan-0.1    0x114e3f0    20863     66       0       OK
         CAS-TCP    0x114ebc0    20864     18       0       OK
      CAS-beacon 0x7f043c000990    20865     17       0       OK
         CAS-UDP 0x7f0440000970    20866     16       0       OK

The _main_ thread is not started using epicsThreadCreate() and thus never runs the thread_hook, so we don't know its LWP ID.  It would be nice if we could see it here.  The _main_ thread gets its epicsThreadOSD structure created and added to pthreadList inside the once() routine in od/posix/osdThread.c before epicsThreadHooksInit() is run.  The Init() routine cannot call any other epicsThread... routines such as epicsThreadGetIdSelf() because once() hasn't finished yet.  Maybe epicsThreadHooksInit() could take main's epicsThreadId as an argument and (if non-zero) call the StartHook for it?

I think we can safely forget about calling _main_'s ExitHook, which brings up the interesting question of whether ExitHook is actually needed -- any StartHook can register an epicsAtThreadExit() routine if it needs to do clean-up.  If we were to remove the ExitHooks we would never have problems with an ExitHook being called for a thread for which where there was no corresponding StartHook.  It also means that the ExitHook routines would be run in the reverse order of the StartHook routines, whereas at the moment the order is the same.

- Andrew

-- 
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.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System