…ber. Fixes #28201
…e () and mono_gc_alloc_string ().
…s in Sql Server. This resolves https://bugzilla.xamarin.com/show_bug.cgi?id=26546.
…rativeness into the runtime. Coop requires the following set of rules: -blocking code must be wrapped with MONO_PREPARE_BLOCKING / MONO_FINISH_BLOCKING Must not read managed refs read/writes inside the block Managed memory (i.e. inside a byte) must be previously pinned -state escaping transitions (lazy thunks and others sneaky n2m transitions) must be wrapped with MONO_PREPARE_RESET_BLOCKING / MONO_FINISH_RESET_BLOCKING This lands the thread in runnable state, so be careful to keep it suspendable by following the target environment rules. The set of rules for what runtime code can/can't are still in flux, but here's the tentative list: == On Wrapping syscall/waits - Wrap it on the callee. We can't necessarily know in which context the syscall will be called. This will reduce reentrancy issues as blocking is not reentrant. - Don't go blocking while holding locks as this will certainly deadlock. - Avoid allocating memory while holding locks. - Annotate blocking restrictions in the comments in the same way we do it for locking. == On aborting blocking - Avoid it as much as possible as it might lead to unbound pauses. - Make sure you can always restore back to blocking.  Since we conservatively scan the native stack, acquiring the ref outside of the block is enough for now.
…nd code. Make sure all logging include the thread tid to ease correlation. Add counters to check for proper balance of post/wait on the suspend semaphore. Massive improvement in the coop suspend wait timeout crasher. It will now print a cue card on the internal states. This makes finding the offending threads much easier.
…gating operator. Fixes #28435
…y, as Microsoft does in .NET Framework 4.5 See MSDN https://msdn.microsoft.com/en-us/library/system.windows.markup.valueserializerattribute(v=vs.110).aspx
…same info is already available using another callback.
It didn't work with referencesource.
It caused name conflict with internal Sys.Data type (due to InternalsVisibleTo).