Hi,
What is the expected behavior when a user runs multiple instances of a TurboFloat app in a single session?
Let's say call them Instance A (started first) and Instance B (started second). I'm seeing some unusual behavior in Instance B. In particular, when starting Instance B:
1) Instance B calls TF_HasLease, which says that there is no lease.
2) Instance B calls TF_RequestLease and is able to successfully request a lease. However, watching the TurboFloat server logs (which is set to log at the Notification level), it is clear that it's actually not consuming an additional lease, as the lease use count stays at 1. At this point Instance A and Instance B appear to be actually sharing a lease, but they're both unaware of it.
3) Now, the user quits Instance B, which calls TF_DropLease. This drops the lease for Instance A *AND* Instance B, and the TurboFloat server reports that the lease use count has dropped to 0.
It is this last behavior that feels unexpected, because it is not symmetric with (1) or (2). It's also not great that Instance A loses its lease because the user quit Instance B.
This is technically solvable at the app level by implementing inter-process communication with the apps, and having Instance B ask Instance A whether it has a lease before dropping it.
Is there a more elegant way to solve this problem using only the TurboFloat API? I'm not sure what form this would take, but if there's some way to know if the session already has a lease, or some way to drop the lease from one instance without dropping it for all instances, that'd be ideal.
