Closed hallsbyra closed 2 years ago
await
ing your feedback before I proceed to fix compilation warnings! :)
This is a good idea. There are two areas that should be addressed before adding it to the main repo. I worry that starting a new connection would fail while the old one is attempting to close. Not sure if the client would even know if it failed.
I'm not sure I follow. Do you mean a client could do something like this:
c1 = cp.StartConnection(con1);
c2 = cp.StartConnection(con1);
I would say that is illegal. One would have to do this:
c1 = cp.StartConnection(con1);
await cp.StopConnection(c1);
c2 = cp.StartConnection(con1);
That should be fine.
I agree, the first one should not be allowed. I believe an Invalid Operation Exception response would be an appropriate response.
The second scenario is the concern I had with the preceding comment. If it is running on the same thread, there should be no issues with the change. There could be an issue when the shutdown is on a different thread from the connection staring back up. While the second the statement is waiting for a shutdown, how will the third statement behave on a different thread? It appears that it will not connect and the client won't get any feedback. Ideally, it would wait for the shutdown to complete and attempt to connect within the timeout. If it easier, it could also return the Exception as described above.
What do you think?
Sorry for the delay - took some Easter leave! :) Anyway, my take on the above is that if it is illegal to start a new connection before the old one is completely closed, then it does not matter whether this happens in a single thread or from multiple threads - it should still be illegal. The rule is: you must ensure a connection is fully stopped before starting it again. This PR enables the client to enforce that rule, by letting it observe the Task
and wait for its completion.
I fear that trying to synchronize IOsdpConnections
between Bus
es can be a can of worms. In my view it would be like if you passed the same Stream
instance to several StreamReaders
and expect that they would somehow sort out how to cooperate on that single Stream
.
If we should do anything at all to prevent the same connection from being misused I can think of two pretty simple checks:
StartConnection
, ensure that the passed connection instance is not already used by any Bus
.StartConnection
, ensure that the passed connection is not already connected.However, I see problems with both... Apart from thread synchronization issues, it could still come down to semantics. What if two different SerialPortOsdpConnections
instances are started, but they use the same serial port (COMx)? Should we try to prevent that as well?
In short, my suggestion is to not try to be oversmart in the ControlPanel
. Keep it simple. Don't you agree?
Agreed, throw an exception if the polling task is still running. We should at least let the caller know that it didn't start a new connection.
Ok. I added a check in StartConnection. Let me know what you think.
By making StopConnection async we expose the inherently async nature of stopping a connection.
Currently, a Poll task is started in StartConnection and then it is signalled to stop in StopConnection. There are a few issues with this.
This PR
Having StopConnection return Task is a "somewhat" breaking change. Old code will compile, but with a warning. To get rid of the warning one can either