You're quite hitting something,
Lefteous. Thank you!
As I said, there's quite some silent assumptions in there, and it definitely needs improvement.
The point you spotted, ie the fact that the actual arg to `contentStopGetValue` (the fileName) is in no way explicitly connected to the thread I'm calling `.interrupt()` on is indeed as bad "hackery" as it can get...
It does, however, work because
- TC calls `contentStopGetValue` only after `contentGetValue` had returned FT_DELAYED and then again `contentGetValue` was called without being allowed to delay it,
- AND these three calls are all on the same fileName, in succession
- AND there won't be any other intermediate calls re different files in between
- AND TC performs these calls in no more than two threads.
Anyways, there's no question that this needs to be improved, even if TC's calling pattern is not very likely to change soon.
You might have noticed all the "TODO" and "assuming..." comments in the code I posted above...
Lefteous wrote:In addition it seems you actually interrupt a TC thread. If yes I think this should be avoided.
Yep, that's an interesting point which I don't fully understand myself.
First off, in java, `interrupt`ing a thread is not so big a deal. It's basically nothing but atomically setting a boolean variable to true which is local to thread.
It's totally up to the `interrupt`ed thread itself (well, except...*) to
a) test this variable every now and then (and the channels do)
b) how to react on a change (channels close themselves and throw an `AsynchronousCloseException` or `ClosedByInterruptException`)
c) whether to clear this flag or not (channels DON'T)
So, `interrupt`ing a java thread is not at all like a `suspend` or even `destroy`; rather like a polite request, which may very well go unheared altogether.
Next, all exceptions that come from either an IO error or from an interruption are caught in my `contentGetValue` and then either FT_FILEERROR or FT_FIELDEMPTY is returned, respevtively.
That is to say: in these ("normal") cases, the thread just keeps on living happily.
Finally - and that's what I don't understand completely - even if some arbitrary uncaught exception is thrown, the only thing that happens is a dialog from tc_java showing up, stating that exception.
And TC seems to receive an FT_FILEERROR or FT_FIELDEMPTY, probably due to the magic of tc_java.
But apart from that, the thread does live on. This is for sure, I'm getting normal calls on the
very same threads even after such events.
I haven't investigated so far how this actually works, but I will eventually.
So, at least for the moment it feels quite safe to just say "well, I'm simply never going to kill a TC thread - whatever I may do". Thanks to Ken, I suppose...
---
Thanks again,
Lefteous, for your comment and the definitely attentative observations.
How to handle java's annoying exception system, and how to make the API fit it as best as possible is a topic of its own (the Iterable pattern with `contents(...)` is NOT optimal!).
And sorry if my answer was much longer than you might have wished. Just couldn't make it any shorter.
___
* "well, except...": not important here, but I'll try to explain if you want me to