-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement named synchronization primitives to be system wide #4370
Comments
I'm taking a look at this issue. |
Update PAL APIs that create named objects (mutex, semaphore, event, file mapping) to return a not-supported error code. It was decided to not support cross-process synchronization in PAL at present time due to complexities involved in reliably emulating Windows' behavior. @stephentoub has already made changes on the FX side to throw PlatformNotSupportedException in these cases. Related to issue #1237.
Update PAL APIs that create named objects (mutex, semaphore, event, file mapping) to return a not-supported error code. It was decided to not support cross-process synchronization in PAL at present time due to complexities involved in reliably emulating Windows' behavior. @stephentoub has already made changes on the FX side to throw PlatformNotSupportedException in these cases. Related to issue #1237.
Update PAL APIs that create named objects (mutex, semaphore, event, file mapping) to return a not-supported error code. It was decided to not support cross-process synchronization in PAL at present time due to complexities involved in reliably emulating Windows' behavior. @stephentoub has already made changes on the FX side to throw PlatformNotSupportedException in these cases. Related to issue #1237.
Update PAL APIs that create named objects (mutex, semaphore, event, file mapping) to return a not-supported error code. It was decided to not support cross-process synchronization in PAL at present time due to complexities involved in reliably emulating Windows' behavior. @stephentoub has already made changes on the FX side to throw PlatformNotSupportedException in these cases. Related to issue #1237.
@stephentoub I'm curious why this and every issue around this is closed. This is a valid use case that's needed https://github.com/dotnet/coreclr/issues/3422 Just because we now throw platform not supported exception isn't a valid fix to mark it as closed :(, unless this will never be supported. We needed a named mutex under System.Security.AccessControl but it appears that it references a ton of Win32 and System.Security.Prinicpal.Windows and this fails to install under xamarin (which now supports .net standard).. |
Named Mutexes are supported on Unix as of 1.0.
We currently have no plans to add named synchronization primitive support on Unix to other primitives. We throw for the same reason Mono throws: there's currently no good way to support it in a robust way. |
I think a bug needs to be opened for System.Security.AccessControl package to specify that it's a windows only dependency.... |
They can easily leak: |
Feel free to open an issue. |
@stephentoub Do you have any recommendations for replacing this or should we just not support it on net standard as we can't guarantee it will be supported + it won't install via nuget on non windows (macos + xamarin) https://github.com/exceptionless/Exceptionless.Net/blob/master/src/Exceptionless/Utility/SingleGlobalInstance.cs |
@ericstj, I thought we had default implementations that throw PlatformNotSupportedExceptions for these Windows-specific libs... is that not the case for this one, or is there another package that needs to be referenced to get them? |
When we try and install https://www.nuget.org/packages/System.Security.AccessControl/ on xamarin projects we get Looking at it further it also references |
Yes we do.
That's because the xamarin platforms don't use a RID to restore. I've added more detail in the issue you opened.
That's fine, Win32.Primitives is cross-plat. It contains Win32Exception which is implemented everywhere. |
@niemyjski I see this was closed but was it resolved successfully or is it won't fix? .Net Core 3.0, Linux, ala EventWaitHandle. "The named version of this synchronization primitive is not supported on this platform." |
Where it could be supported (e.g. Mutex), it is, and for the rest it throws PlatformNotSupportedException, by design. |
Hey @stephentoub, except for Mutex, what else is supported? Cheers |
Just Mutex. Semaphore and EventWaitHandle don't support named primitives today on unix. |
System.Threading.Semaphore, Mutex, and EventWaitHandle (ManualResetEvent, AutoResetEvent) all support being passed names. On Windows, these names are cross-process, with this being one of the primary mechanisms apps use to coordinate across processes. On Unix these types rely on functionality in the CoreCLR Win32 PAL, which today implements these names only as process-wide. Anyone attempting to use these types for cross-process synchronization (the primary use case) could easily find themselves with bad race conditions when running on Unix.
We should reimplement this PAL functionality to use system-wide rather than process-wide names.
(Replaces #4054.)
The text was updated successfully, but these errors were encountered: