Mark Rivers

@norumwe12 can you comment on this issue? Michael Davidsaver suggested that we could have a non-blocking call to connect() and then use select() to determine if it has connected and...

@mdavidsaver wrote: >I happened to notice that Base has a hidden connectWithTimeout() defined for RTEMS. The comment at the top of the file suggests that there is a similarly named...

> Why do we have to wait for connection in the first place to set the input / output EOS? Isn't this independent of the connection status? That is a...

@ebernalru I have created a PR (#210) based on your patch file. I removed the debugging print statements from the patch version, and I changed the cast for the timeval...

> In addition, I think the remaining size of tty->UDPbuffer[] should be checked before the reading of maxchar characters, otherwise it seems to me that there is nothing stopping a...

Hi Martin, I'm on vacation so I can't test this. But the underlying problem is a limitation in asynManager. The first thing that asynPortDriver does (indirectly) is call pasynManager->registerPort("portName"). The...

C++ drivers written using asynPortDriver will presumably have a destructor that does the work of tearing down the port driver, and then calls pasynManager->unregisterPort() at the end. Many such drivers...

I think this issue is worth pursuing, but I suspect it will take a while to finish it, so I would like to postpone until after asyn R4-31 is released.

I don't really see any point in calling pasynManager->unregisterPort() using an epicsAtExit callback. What is the point, since all of the resources are about to be freed by the OS...

And the one place it is used is only for Model 1 drivers which should never be used for new drivers.