public void Stop()
{
// Locked to avoid contention with code in the thread that reports a transfer complete,
// which disposes of _wifiSender and tries to restart the advertiser.
lock (this)
{
if (_wifiAdvertiser != null)
{
_wifiAdvertiser.Stop();
_wifiAdvertiser.Dispose();
_wifiAdvertiser = null;
}
if (_wifiSender != null)
{
_wifiSender.CancelAsync();
Debug.WriteLine("attempting async cancel send");
}
if (_uploadTimer != null)
{
_uploadTimer.Stop();
_uploadTimer.Dispose();
_uploadTimer = null;
}
}
// To avoid leaving a thread around when quitting, try to wait for the sender to cancel or complete.
// We expect another thread to set _wifiSender to null in the UploadDataCompleted event
// (which is supposed to be triggered also by canceling).
for (int i = 0; i < 30 && _wifiSender != null; i++)
{
Thread.Sleep(100);
}
lock (this)
{
if (_wifiSender != null)
{
// If it's still null we give up on the Cancel and try to shut it down any way we can.
// Note that if the cancelAsync didn't work, as it generally seems not to, this could
// cancel a file transfer rather abruptly. But the alternative is to leave the thread
// running, possibly after Bloom has otherwise exited, causing problems like BL-5272.
// (In practice even aborting this thread doesn't seem to force the file transfer to
// stop, nor does anything else I've tried, so we just do our best to make sure
// the thread won't outlive the application by much. Not allowing requests to queue
// up is one thing that helps. At worst there's only one in progress that either
// finishes or aborts before too long.)
_wifiSender.Dispose();
_wifiSender = null;
Debug.WriteLine("had to force dispose sender");
}
}
if (_wifiListener != null)
{
{
_wifiListener.StopListener();
_wifiListener = null;
}
}
}
