+2007-09-25 Jonathan Pobst <monkey@jpobst.com>
+
+ * SynchronizationContext.cs: Implement SetSynchronizationContext.
+
+2007-09-06 Dick Porter <dick@ximian.com>
+
+ * Timer.cs: Only hold a WeakReference to the runner thread, to
+ work around an issue when finalizing at shutdown or (I think)
+ appdomain unload. (Basically, the Thread was being finalized
+ first, but the Timer's finalizer was still trying to reference it
+ subsequently.)
+
+2007-08-10 Gert Driesen <drieseng@users.sourceforge.net>
+
+ * Thread.cs: Throw ThreadStateException when retrieving ApartmentState
+ or IsBackground if thread is stopped. Fixes bug #81658.
+
+2007-08-08 Zoltan Varga <vargaz@gmail.com>
+
+ * Thread.cs: Add a fixme.
+
+2007-07-21 Miguel de Icaza <miguel@novell.com>
+
+ * WaitHandle.cs (Handle): It turns out that we should never create
+ new SafeWaitHandles, as applications will assume that a
+ SafeWaitHandle pulled from this will be the same after a Handle
+ update (from Gert's test):
+
+
+ AutoResetEvent are1 = new AutoResetEvent (false);
+ AutoResetEvent are2 = new AutoResetEvent (false);
+ SafeWaitHandle swh1 = are1.SafeWaitHandle;
+ Console.WriteLine ("#A1:" + !swh1.IsClosed);
+ Console.WriteLine ("#A2:" + !swh1.IsInvalid);
+ IntPtr dummyHandle = (IntPtr) 2;
+ are1.Handle = dummyHandle;
+ Console.WriteLine ("#A3:" + (are1.Handle == dummyHandle));
+ Console.WriteLine ("#A4:" + !swh1.IsClosed);
+ Console.WriteLine ("#A5:" + !swh1.IsClosed);
+ Console.WriteLine ("#A6:" + !swh1.IsInvalid);
+ Console.WriteLine ("#A7:" + !are1.SafeWaitHandle.IsClosed);
+ Console.WriteLine ("#A8:" +
+ !are1.SafeWaitHandle.IsInvalid);
+
+ We would return in A4, A5, A6 true, even when we have set the
+ Handle ourselves.
+
+ *
+
+2007-07-18 Miguel de Icaza <miguel@novell.com>
+
+ * WaitHandle.cs (Handle): in the 2.0 profile, explicitly dispose
+ the old SafeWaitHandle, do not wait for the finalizer to run;
+
+ Take ownership of the handle; The docs did not say that
+ assigning to this value would lead to a leak, the docs said that
+ in the 1.0 and 1.1 profiles assigning to this property might lead
+ to a leak. My mistake.
+
+ Fixes: 82134
+
+2007-07-09 Atsushi Enomoto <atsushi@ximian.com>
+
+ * LockCookie.cs, AsyncFlowControl.cs :
+ added missing operator == and !=.
+
+2007-05-22 Jonathan Chambers <joncham@gmail.com>
+
+ * Thread.cs: Use & to check ThreadState rather than ==.
+ Fixes AlbumSurfer regression.
+
+2007-05-09 Jonathan Chambers <joncham@gmail.com>
+
+ * Thread.cs: Implement ApartmentState related items.
+
+2007-05-02 Dick Porter <dick@ximian.com>
+
+ * ReaderWriterLock.cs: ReaderWriterLock derives from
+ CriticalFinalizerObject in the 2.0 profile
+
+2007-05-01 Dick Porter <dick@ximian.com>
+
+ * ThreadState.cs:
+ * AsyncFlowControl.cs:
+ * Interlocked.cs:
+ * RegisteredWaitHandle.cs:
+ * TimerCallback.cs:
+ * ThreadStateException.cs:
+ * Monitor.cs:
+ * ThreadStart.cs:
+ * WaitOrTimerCallback.cs:
+ * LockCookie.cs:
+ * EventWaitHandle.cs:
+ * WaitHandle.cs:
+ * ThreadAbortException.cs:
+ * ThreadPriority.cs:
+ * ReaderWriterLock.cs:
+ * NativeOverlapped.cs:
+ * Mutex.cs:
+ * Overlapped.cs:
+ * ThreadPool.cs:
+ * ApartmentState.cs:
+ * EventResetMode.cs:
+ * SynchronizationLockException.cs:
+ * ManualResetEvent.cs:
+ * WaitCallback.cs:
+ * IOCompletionCallback.cs:
+ * AutoResetEvent.cs:
+ * AbandonedMutexException.cs:
+ * SendOrPostCallback.cs:
+ * ThreadInterruptedException.cs: Update to 2.0 profile
+
+Thu Apr 19 16:47:52 CEST 2007 Paolo Molaro <lupus@ximian.com>
+
+ * ThreadPool.cs: patch from Robert Jordan to implement
+ ThreadPool.SetMaxThreads.
+
+2007-04-03 Alp Toker <alp@atoker.com>
+
+ * Monitor.cs: Class is static in 2.0.
+
+2007-03-27 Dick Porter <dick@ximian.com>
+
+ * Mutex.cs: Throw ApplicationException if ReleaseMutex() fails.
+ Fixes bug 79358.
+
+Tue Jan 23 17:43:50 CET 2007 Paolo Molaro <lupus@ximian.com>
+
+ * Thread.cs: mark the GC-tracked field with UIntPtr.
+
+2006-12-31 Miguel de Icaza <miguel@novell.com>
+
+ * ThreadPool.cs: Stub a method.
+
+2006-12-11 Miguel de Icaza <miguel@novell.com>
+
+ * WaitHandle.cs: In 2.0 use SafeWaitHandles and the SafeWaitHandle
+ patterns instead of using directly the IntPtr Handle.
+
+ Refactor the code to reuse as much as possible, and follow the new
+ conventions where appropriate.
+
+2006-11-07 Robert Jordan <robertj@gmx.net>
+
+ * WaitHandle.cs: Don't assume Assembly.GetEntryAssembly () !=
+ null. Fixes bug #79859.
+
+2006-11-02 Dick Porter <dick@ximian.com>
+
+ * Thread.cs: Use the new Interrupt and SpinWait icalls.
+
2006-07-04 Atsushi Enomoto <atsushi@ximian.com>
* WaitHandle.cs : CheckArray() is also used in WaitAny(), so added
projects / mono.git / blobdiff