Open
Description
Hi,
I've come across a scenario where subsequent instances crash with the following error:
System.TimeoutException: Gave up waiting for read lock
at TinyIpc.Synchronization.TinyReadWriteLock.AcquireReadLock() in /_/src/TinyIpc/Synchronization/TinyReadWriteLock.cs:line 130
at TinyIpc.IO.TinyMemoryMappedFile.Read() in /_/src/TinyIpc/IO/TinyMemoryMappedFile.cs:line 158
at TinyIpc.Messaging.TinyMessageBus..ctor(ITinyMemoryMappedFile memoryMappedFile, Boolean disposeFile, TimeSpan minMessageAge) in /_/src/TinyIpc/Messaging/TinyMessageBus.cs:line 111
at TinyIpc.Messaging.TinyMessageBus..ctor(ITinyMemoryMappedFile memoryMappedFile, Boolean disposeFile) in /_/src/TinyIpc/Messaging/TinyMessageBus.cs:line 90
at TinyIpc.Messaging.TinyMessageBus..ctor(String name) in /_/src/TinyIpc/Messaging/TinyMessageBus.cs:line 63
at SingleInstanceCore.SingleInstance.SignalFirstInstance(String channelName, IList`1 commandLineArgs)
at SingleInstanceCore.SingleInstance.InitializeAsFirstInstance[T](T instance, String uniqueName)
This happens when multiple files are selected and opened from Windows File Explorer, each file starting an instance of my application and then all these instances end up trying to signal the first instance at the same time. I've worked around this in my code by setting up a named Mutex that only allows one instance at a time calling InitializeAsFirstInstance:
using (var mutex = new Mutex(false, uniqueAppName))
{
try { mutex.WaitOne(3000); } catch (AbandonedMutexException) { }
try
{
if (!this.InitializeAsFirstInstance(uniqueAppName))
Environment.Exit(0);
}
finally
{
mutex.ReleaseMutex();
}
}
This works, but it would probably be better if SingleInstanceCore handled this internally, inside the SingleInstance.SignalFirstInstance method.
Thanks for making this library available!
Metadata
Metadata
Assignees
Labels
No labels