RE: building Posix for win32-x86?

["Jeff Hill" <johill@lanl.gov>]

> I did commit this change to libCom/osi/os/WIN32/osdThread.c about 2
> weeks ago, in epicsThreadOnceOsd():
>

I also saw that this was the problem yesterday. There is a situation in the
windows osd time initialization (this is a once function called from
epicsTime::getCurrent) where a timer has to be started after all of the core
osd time initialization completes, but this calls epicsTime::getCurrent()
which calls the initialization again, and the new assert fail is experienced
(the assert message seems to need the current time also BTW and so it
currently is recursively blowing the cork on the stack adding to the
spectacular nature of the failure).

I don't see any solution other than to explicitly set the once id to one
after the core initialization completes but before the timer is started
(inside of the once function). I don't really like to see that level of
coupling between the two modules (for example my module needs to know that
one is a magic value and there is no symbol defining this constant) but I
don't see any other solution which might be more palatable, and does not
require large code changes, at the moment.

Jeff

> -----Original Message-----
> From: Andrew Johnson [mailto:anj@aps.anl.gov]
> Sent: Tuesday, November 21, 2006 9:07 AM
> To: Jeff Hill
> Cc: Janet Anderson; 'EPICS Core Talk'
> Subject: Re: building Posix for win32-x86?
> 
> Jeff,
> 
> Jeff Hill wrote:
> > I am chasing down an infinite recursion during init that appears to
> occur on
> > win32-x86 because of an assert failure in epicsThreadOnce. I suspect
> that
> > this is a side effect of a cvs update I did before I committed files on
> > Friday.
> 
> I did commit this change to libCom/osi/os/WIN32/osdThread.c about 2
> weeks ago, in epicsThreadOnceOsd():
> 
> Index: osdThread.c
> ===================================================================
> RCS file:
> /net/phoebus/epicsmgr/cvsroot/epics/base/src/libCom/osi/os/WIN32/osdThread
> .c,v
> retrieving revision 1.52.2.13
> retrieving revision 1.52.2.14
> diff -u -b -r1.52.2.13 -r1.52.2.14
> --- osdThread.c 11 Nov 2005 01:47:07 -0000      1.52.2.13
> +++ osdThread.c 10 Nov 2006 20:19:34 -0000      1.52.2.14
> @@ -999,10 +999,12 @@
> 
>       EnterCriticalSection ( & pGbl->mutex );
> 
> -    if ( ! *id ) {
> +    if ( *id == 0 ) {
> +        *id = -1;
>           ( *func ) ( arg );
>           *id = 1;
> -    }
> +    } else
> +        assert(*id > 0 /* func() called epicsThreadOnce() with same id
> */);
> 
>       LeaveCriticalSection ( & pGbl->mutex );
>   }
> 
> The purpose of this assertion is to detect a situation that the posix
> version of epicsThreadOnceOsd() is unable to handle or even detect since
> posix mutexes are not recursive.  This might cause an infinite loop if
> assert() calls errlogInit() which calls epicsThreadOnce(), but that
> situation could only occur if func() has itself first called
> epicsThreadOnce() with the same id.
> 
> > When attempting to fix that I am seeing a real weird situation where it
> is
> > building posix code when EPICS_HOST_ARCH == WIN32-x86.
> 
> I have no explanation for that.
> 
> - Andrew
> --
> There is considerable overlap between the intelligence of the smartest
> bears and the dumbest tourists -- Yosemite National Park Ranger