I think that you would be better off converting everything over to use the EPICS API -- epicsThreadCreate(...)and such.
This will be a better fit to EPICS and makes your driver useful to RTEMS folks, too.
On May 1, 2011, at 7:38 PM, Szalata, Zenon M. wrote:
> Till, Thank you for your input.
> I understand your suggestion.
> There is another related issue, which I am not sure about.
> In the existing driver code, the task is created with a call to vxWorks routine taskSpawn(...). Here is a code fragment:
>
> int status;
> ...
> status=taskSpawn(...);
> ...
> taskwdInsert( status,NULL,NULL);
> ...
>
> This does not compile since taskwdInsert expects the first argument of type epicsThreadId.
>
> I am making a wild guess, that perhaps, before calling taskwdInsert routine, I need to call epicsThreadGetID, which should return epicsThreadId type identifier, which then I could pass to taskwdInsert.
>
> Seems that it should work, but having little experience with tasks, I would like an assurance that this the right way.
>
> Thanks Till,
> Zen
>
>> -----Original Message-----
>> From: Till Straumann [mailto:[email protected]]
>> Sent: Saturday, April 30, 2011 11:26 PM
>> To: Szalata, Zenon M.
>> Cc: Williams Jr., Ernest L.; EPICS Tech Talk
>> Subject: Re: EPICS task watch dog
>>
>> It seems that the epicsThreadId in the vxWorks implementation of
>> OSI is just the vxworks TID. Hence, passing a vxworks TID that
>> you obtain using straight vxworks calls on to EPICS and casting
>> to (epicsThreadId) should work but is of course extremely
>> ugly since you rely on non-public implementation details
>> (and you have no guarantee that these will not change in
>> future EPICS releases).
>>
>> Your example would be much better using EPICS APIs only:
>>
>> epicsThreadId tid;
>>
>> /* EPICS_THREAD_NAME is 'const char *' */
>>
>> if ( (tid = epicsThreadGetId( EPICS_THREAD_NAME )) ) {
>>
>> taskwdRemove( tid );
>>
>> /*** see comment ***/
>> }
>>
>> Note that the EPICS API doesn't offer an equivalent for
>> 'taskDelete()' and this probably for good reasons: Just
>> asynchronously deleting a task is almost always a very bad
>> idea since you have no control over what the task is doing
>> when you pull the rug under its feet.
>>
>> You need to implement a synchronization mechanism to let
>> the task know that it should terminate and then wait
>> for termination instead of using 'taskDelete()'.
>>
>> HTH
>> -- Till
>>
>>
>> On 04/30/2011 11:08 PM, Szalata, Zenon M. wrote:
>>> I am working to upgrade an old device driver module so it can be used
>>> with EPICS R3.14.11 and vxWorks 6.6. It is currently used with EPICS
>>> R3.13.2 and some older version of vxWorks. The author is using the task
>>> watchdog routines in a way that I find confusing and am not able to make
>>> a decision on how to proceed.
>>>
>>> The task watchdog routines in EPICS R3.13.2 take int argument. An
>>> example is void taskwdRemove(int tid).
>>>
>>> In EPICS R3.14.11 this routine is now epicsShareFunc void
>>> taskwdRemove(epicsThreadId tid).
>>>
>>> The argument is now is a pointer to a structure. In itself, that is not
>>> surprising. The confusing part is that the author is using vxWorks
>>> routines, which use an int type handle and the EPICS routines which are
>>> called with the vxWorks handles. Here is a code fragment:
>>>
>>> int tid;
>>>
>>> if ( (tid = taskNameToId( NAME )) != ERROR )
>>>
>>> {
>>>
>>> taskwdRemove( tid );
>>>
>>> taskDelete( tid );
>>>
>>> }
>>>
>>> Compiler does not like this because an int type is passed where a
>>> pointer to a structure is expected.
>>>
>>> Type casting the argument to the correct type would please the compiler,
>>> but I fail to see how this could possibly work correctly.
>>>
>>> Part of my problem is that I started to work with EPICS with R3.14.9, so
>>> R3.13.2 seems prehistoric
>>>
>>> Someone might ask a legitimate question, why bother with this old code?
>>> In fact I have a new device driver, which works with new applications.
>>> Unfortunately, the "old" IOC, which is using the driver in question is
>>> using a fairly extensive set of records and these would have to be
>>> modified substantially to make the IOC work with a new device driver
>>> code. So, I think that upgrading the device driver and preserving the
>>> .db files is more likely to result in the upgraded IOC working as it did
>>> before.
>>>
>>> Any ideas are most welcome,
>>>
>>> Zen
>>>
>
>
--
Eric Norum
[email protected]
- References:
- EPICS task watch dog Szalata, Zenon M.
- Re: EPICS task watch dog Till Straumann
- RE: EPICS task watch dog Szalata, Zenon M.
- Navigate by Date:
- Prev:
RE: EPICS task watch dog Szalata, Zenon M.
- Next:
Re: EPICS task watch dog Andrew Johnson
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
<2011>
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: EPICS task watch dog Szalata, Zenon M.
- Next:
Re: EPICS task watch dog Andrew Johnson
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
<2011>
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|