Q: Proper Sequence of Destroying a Tag about libplctag HOT 2 CLOSED

Internally, plc_tag_destroy calls plc_tag_abort (not exactly, but close). So you can call plc_tag_destroy at any time. I added the plc_tag_abort function to the public API so that applications could make decisions about aborting operations. If you use the asynchronous version of calls like plc_tag_read (no timeout), then it is up to your application logic to decide whether to time out or not. At that point you will need to call plc_tag_abort before you can call another plc_tag_read or plc_tag_write.

Now that the API is threadsafe (crosses fingers...) you can leave off the plc_tag_lock and plc_tag_unlock parts unless there is an operation you want to keep atomic. For instance if you want to increment a counter in the PLC, you would probably want to do the following:

plc_tag_lock

plc_tag_read

... get the value, increment it, put it back into the tag...

plc_tag_write

plc_tag_unlock

If another thread is using a tag that I am trying to destroy, assuming that it's locked, can/should I abort it before unlocking it?

It depends on why you locked it. Locking is to make sure that other application threads cannot access the tag. As I mentioned above, you do not need to abort before calling plc_tag_destroy.

Should I use my own scoped mutex to make sure all threads are not running before destroying all tags?

That is hard to answer without knowing the logic of your application. You can call plc_tag_destroy in any thread and the other threads will start getting errors, but they should not crash due to the library.

Do I need to lock and unlock tags if I use my own mutex?

No, the tag mutex is only there for systems where you do not have your own mutex. It is just for application code. Arguably I probably should not have added it to the API.

Will a tag ever get stuck and never return? (would aborting it fix this issue?)

Calling plc_tag_status "tickles" the internals of the library giving it time to run. So, as long as you keep calling plc_tag_status once in a while, the library is not dead. You can have failure in various ways (network, end PLC etc.) that cause operations to fail. If you are seeing a real hang where you are not calling plc_tag_status once in a while, then there is a bug in the library.

When you call things like plc_tag_read in synchronous mode (i.e. you have a timeout), then there is a loop that runs inside the code counting off the milliseconds and checking the status. If that hangs, there is a bug in the library.

If you have a complete hang of the library, then it is a bug. I suspect that calling plc_tag_abort at that point will not make things better :-/

All IO is handled in a background thread in the library. If you look at the debugging output, you will probably see at least one thread more than you have in your application. That extra is the IO thread. This was done to decouple the front end of the API from the implementation back end.

Be aware that there are some network operations that can take a really long time to time out. The biggest one right now is if you pass the host/gateway parameter with a host name instead of an IP address. This calls the DNS resolver library and I have seen cases in the past where DNS can get screwed up and take 90 seconds or more to time out. For industrial applications, I almost never use host names for this reason. There are also a few edge cases where certain parts of TCP shutdown can take a long time. I think I have those covered thanks to a few bug reports that helped isolate the issue, but there may be some more edge cases.

from libplctag.

OK. Thank you for answering my questions. I will update my contrib code with these things in mind.

from libplctag.