minor fix for bug 9520:
- socket configuration attempts to determine if system supports ipv6
- checks app configuration, but configuration throws exception if called from embedded context
- solution is to put a try/catch guard and fall to an alternative test for ipv6
Improve detecting if a handle is a console on Windows.

Use GetConsoleMode. If it succeeds (returns non-zero) then the handle is a
console. If it fails (returns zero) then the handle is not a console.

The old check, (GetFileType (handle) == FILE_TYPE_CHAR) assumes that a handle
of type FILE_TYPE_CHAR is a console. This falsely reports a handle directed to
NUL as a console.

Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=12752
Add TimeZoneInfo Serialization

Add serialization for the TimeZoneInfo, TimeZoneInfo.AdjustmentRule and TimeZoneInfo.TransitionTime class. It is compatible with the serialization in .Net for cross serialization/deserialization from Mono to .Net and vice versa.

The code in this commit is released under the terms of the MIT/X11 license.
There was a long discussion on a mailing list about the async-socket problem
in mono. We have previously submitted a patch fixing the problem, however it
was later reverted back as causing deadlocks in some cases.

This patch is very close to the original one, but it takes into account how
tpool-thread operates and avoids deadlocks in this code. (Unfortunately, it
probably makes the code a little less readable, but it works).

So, this patch aims to fix several races in the mono code. These problems are
not relevant for a lot of applications as they can appear only if both read
and write operations are active on the socket. (I.e. RPC style communications
do not trigger the problem).

So, there are two major problems with existing mono code:

a) threadpool.c :: socket_io_add

LeaveCriticalSection (&data->io_lock);
data->modify (data->event_data, fd, state->operation, ievt, is_new);

the problem is that data modify receives ievt and is_new arguments which
may be already outdated due to the concurrent operation on the same socket
(read vs. write).

(If you look at the other part of the operation in
tpool_epoll.c :: tp_epoll_wait updates the epoll settigs under the lock.)

b) The epoll implementation uses the following code to change the epoll
settings in the data->modify handler.

if (epoll_ctl (data->epollfd, epoll_op, fd, &evt) == -1) {
  int err = errno;
  if (epoll_op == EPOLL_CTL_ADD && err == EEXIST) {
    epoll_op = EPOLL_CTL_MOD;
    if (epoll_ctl (data->epollfd, epoll_op, fd, &evt) == -1) {
      g_message ("epoll_ctl(MOD): %d %s", err, g_strerror (err));
    }
  }
}

Here we have the same problem. If concurrent operation updates epoll between
first epoll_ctl and the second epoll_ctl the second will override concurrent
update.

These problems result in missing callbacks on async socket send or receive
completion

The original idea was as simple as just move the data->modify under the lock.
(NOTE: both internal associated list and epoll are updated under the lock in
case of data->wait (see tp_epoll_wait).

As i already noted it causes a problem for tpool_poll.c implementation as it
uses different approach than epoll/kqueue.

This patch still invokes data->modify under the lock, but allow implementation
to release lock at the point where it is appropriate for the given
implementation.

The tpool-poll.c releases lock immediately and thus its behavior remains
unchanged (and it still has a problem of missing send/receive callbacks)

The tpool-epoll/kqueue implementations update their internal structures and
corresponding OS level structures under the locks (as _wait does). This change
makes them reliable in simultaneous socket read/write scenarios.

The following code demonstrates the problem. See readme inside.

https://github.com/ysw/mono-socket-problem/tree/master/SocketTest

NOTE: you need at least 4 coresto reliably reproduce the problem.

It is quite hard to reproduce on OSX, but it is easy reproducible in LINUX.

This commit is licensed under MIT/X11.
Simplify emit_write_barrier().

We have two ways of passing in the value - by MonoInst* and by register.
Remove the second and always pass a MonoInst*.
Avoid calling mono_domain_free () in a cross-compiler, it causes a GC, and the unwind infrastructure is not properly set up when cross-compiling.
Disable TestDisposeOnCallback for MONOTOUCH, the test does not really work as the state is null (and throws in a separate thread)
Properly null terminate strings in mono_dwarf_escape_path (). Fixes #13050.
Share byref arguments in runtime invoke signatures with int&. Remove the restrictions on sharing runtime invoke wrappers of valuetype instance methods, its not longer needed.
Remove the async hacks from the gsharedvt code, gsharedvt can now handle async methods, and the infrastructure methods they use.
Make all Mini back ends use mono-hwcap for CPU feature detection.

Also some related cleanup as a result of this.
Check for sys/auxv.h and only use it if available.
Remove the JIT-ed CPUID hack from mono-hwcap-x86.

A proper workaround for the 32-bit PIC issue exists: Using xchg to
unclobber EBX which is used by the compiler. This means we can just
use inline assembly to issue the instruction, eliminating the hack
where we JIT-compiled a function to do the CPUID.

This patch also makes it so that we use MSVC's __cpuid intrinsic
on both 32-bit and 64-bit x86 since it's available on both.
Remove now-unneeded mono_aot_only guard around mono_hwcap_init ().

We no longer use the code manager in any of the hwcap implementations,
so we don't need to disable the hwcap infrastructure in full-aot mode.
Add a MONO_VERBOSE_HWCAP environment variable.

This causes detected hardware features to be printed to stdout.
configure: Remove obsolete FIXME comment.
PowerPC build fix in mono-hwcap-ppc.
Use GCC atomics when USE_GCC_ATOMIC_OPS is defined.

We still prefer Windows.h functions when compiling for Windows, and
MSVC intrinsics for memory barriers when compiling with MSVC.
Enable GCC atomics on x86 and amd64.
Enable GCC atomics on ppc and ppc64.