From: Johnson, Andrew N. <anj@ anl. gov> Sent: Wednesday, February 21, 2024 11: 11 PM To: Yann Mandza <yann. mandza@ ess. eu> Subject: Re: Asyn connection/communication management with asynPortDriver Hi Yann, > I'm not an expert on
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
From: Johnson, Andrew N. <anj at anl.gov>
Sent: Wednesday, February 21, 2024 11:11 PM
To: Yann Mandza <yann.mandza at ess.eu>
Subject: Re: Asyn connection/communication management with asynPortDriver
Hi Yann,
>
I'm not an expert on Asyn port threads but there are several people here who are, so please use the tech-talk list for any follow-up questions.
Another reason that I wrote the above, I unexpectedly got busy this afternoon and might not have time to answer you until next week.
- Andrew
Hi, Andrew
Thanks for the feedback,
What would happen, if during driver initialization, the driver just connects to the port without connecting to the device? then somewhere within the initialization
process, a request is made to connect to the device via the created port. This time the drivers API call will be made inside the port thread, if my understanding is correct ,queued request are executed there? Now, I noticed that autoconnect does cause the
driver connect method to execute from that port thread, but this strangely, this only happen when an output record is part of my DB. So can I queued a connexion request to portthread alongside the port init sequence.
Indeed, the driver API is C++ based, actually, it’s a Qt based code. Am proposing the above because I could circumvent this issue with a test epics device
support by just making sure that all run time access to the device go through the thread that created it. by this I meant epics threads would just queue their requests to a worker thread that owns the device.so am thinking the port thread could just do a similar
thing. Also am trying not to use mutexes, perhaps worst-case scenario.
Regards,
Yann
Hi Yann,
I'm not sure that I completely understand what you're asking or trying to do, but the initialization of EPICS records and device support cannot happen in the Asyn port thread. You should still
be able to structure your port driver though so that it is the only place where API calls are made to the external device library.
The thread protection that you need for that driver doesn't necessarily mean the driver API calls all have to happen within the context of the port thread though, you may just have to create
an epicsMutex for the driver and ensure that the API routines are only ever called by code that has successfully taken that mutex and releases it afterwards. That could get more complicated and my advice might be wrong if the driver is written in C++ or is
multi-threaded, but the latter at least seems unlikely.
I'm not an expert on Asyn port threads but there are several people here who are, so please use the tech-talk list for any follow-up questions.
- Andrew
I would like to use the connection/communication management features of Asyn with a TCP/IP based driver using the asynPortDriver class.
I have a limitation to the underline device driver that expose the device has a non-thread-safe object , meaning it should only be access from the thread
that made the API call to initiate the device handle.
what I want to do, is to create the device handle instance within the asyn port thread, instead of the main thread. thus, all record init and runtime operation
should be performed from inside the asyn porthread. is that possible?
my understand of asyn port drivers is still cloudy somehow. this works, but the handle is hosted by the main thread.
drvXXTest::drvXXTest( const char *portName, const char *interface, const char *icsCtrtype, epicsInt16 autoConnect )
: asynPortDriver( portName,
asynCommonMask | asynInt32Mask | asynUInt32DigitalMask | asynFloat64Mask | asynDrvUserMask | asynOctetMask,
asynCommonMask | asynInt32Mask | asynUInt32DigitalMask | asynFloat64Mask | asynOctetMask,
ASYN_CANBLOCK, // asynFlags.
autoConnect, // Autoconnect
0 ), // Default stack size
static const char *functionName = "drvXXTest";
pasynManager->exceptionDisconnect( pasynUserSelf );
// How to to call devConnect(deviceSession_, interface_) from port thread?
// as this call run from the main one.
asynStatus status = this->connect( pasynUserSelf );
asynPrint( pasynUserSelf, ASYN_TRACE_ERROR,
"drvXXTest, error calling connect - %s\n",
pasynUserSelf->errorMessage );
asynStatus drvXXTest::connect(asynUser *pasynUser) {
// devConnect instantiate the device handle and open a connection to it.
if( !devConnect(deviceSession_, interface_) ) {
epicsSnprintf( pasynUser->errorMessage,pasynUser->errorMessageSize,
"%s: Can't open %s: %s", deviceSession_, interface_, strerror( errno ) );
pasynManager->exceptionConnect( pasynUser );
|