switch away from thread abort where we can

sillsdev / chorus

End-user collaboration library via 3-way xml merging and hg dvcs under the hood

6 stars 26 forks source link

switch away from thread abort where we can #336

Closed hahn-kev closed 4 months ago

hahn-kev commented 4 months ago

closes #335

while writing my tests I discovered that HgProcessOutputReader throws exceptions if redirects are not setup, so I added a comment about that and removed all the code designed to support optional redirects.

I also had to change the ThreadState checks as the threads go to sleep now while waiting to read from the stream, from what I can tell in my tests this new version works all the same.

There were 2 process streams, one was unused so I removed it.

This change is

github-actions[bot] commented 4 months ago

Test Results

      4 files ±  0   412 suites +8 2h 45m 48s :stopwatch: +44s   881 tests +  5   858 :heavy_check_mark: +  5   23 :zzz: ±0 0 :x: ±0 4 032 runs +36 3 898 :heavy_check_mark: +36 134 :zzz: ±0 0 :x: ±0

Results for commit 23507913. ± Comparison against base commit 04e1e281.

:recycle: This comment has been updated with latest results.

jasonleenaylor commented 4 months ago

src/ChorusHub/Advertiser.cs line 72 at r2 (raw file):

          }

          if (_cancellationTokenSource.Token.IsCancellationRequested && cancelled)

Would all conditions that cause a ThreadAbortException also set IsCancellationRequested on the token? Or will it not matter under those circumstances?

hahn-kev commented 4 months ago

src/ChorusHub/Advertiser.cs line 72 at r2 (raw file):

Previously, jasonleenaylor (Jason Naylor) wrote…

Would all conditions that cause a ThreadAbortException also set IsCancellationRequested on the token? Or will it not matter under those circumstances?

in theory there won't be anymore ThreadAbortExceptions, but if there was then IsCancellationRequested would probably be false. So this should probably be ||

hahn-kev commented 4 months ago

src/ChorusHub/Advertiser.cs line 72 at r2 (raw file):

Previously, hahn-kev (Kevin Hahn) wrote…

in theory there won't be anymore ThreadAbortExceptions, but if there was then IsCancellationRequested would probably be false. So this should probably be ||

on the other hand, should we just always close the client? It seems like it should always have been closed and maybe it was just a mistake that it wasn't?

jasonleenaylor commented 4 months ago

src/ChorusHub/Advertiser.cs line 72 at r2 (raw file):

Previously, hahn-kev (Kevin Hahn) wrote…

on the other hand, should we just always close the client? It seems like it should always have been closed and maybe it was just a mistake that it wasn't?

I was thinking it should probably be an || for safety, or just remove the ThreadAbortException if it could only have been triggered by our code. It looks like the client was only closed on Stop via the Abort before and stop is called in the Dispose method.

hahn-kev commented 4 months ago

src/ChorusHub/Advertiser.cs line 72 at r2 (raw file):

Previously, jasonleenaylor (Jason Naylor) wrote…

I was thinking it should probably be an || for safety, or just remove the ThreadAbortException if it could only have been triggered by our code. It looks like the client was only closed on Stop via the Abort before and stop is called in the Dispose method.

alright, I just removed all this and I'm now closing and disposing of the client in Stop. If this class is going to be reused then start needs to be called again, so stop is the logical place to cleanup the client.