[Mono-list] Intrinsicly Non-Portable?

[Serge]

As far as I know, there is already implementation for some pieces you're
referring to.
Check out mono/io-layer/wait.c for example (WaitForMultipleObjects).
Also, perhaps checking Wine's codebase will help sometimes :-)
I also think that some pieces are hard to implement efficiently yet
portable, Threading.Interlocked for example - implemented with mutex it's
surely less efficient.


----- Original Message -----
From: "Christian Ratliff" <cratliff@lily.org>
To: <mono-list@ximian.com>
Sent: Friday, November 23, 2001 11:46 PM
Subject: [Mono-list] Intrinsicly Non-Portable?


>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello all,
>
>   Has anyone given any thought to how we might deal with issues which
> are intrinsically non-portable? By way of example, allow me to offer
> two items.
>
> System.Net.Sockets.Socket.Handle { get }
> This property getter returns a magical value "IntPtr". This value is
> really a kernel event object gained by calling the Winsock function
> ::WSAEVENT ::WSACreateEvent(). This handle value is then attached to
> a socket with the call ::WSAEventSelect(::SOCKET, ::WSAEVENT, long).
> At that point you can nicely block against the ::WSAEVENT.
> No big deal yet, one can easily imagine using ::select() under Unix
> to implement this, and having the socket handle be the magical
> "IntPtr".
>
> System.Threading.WaitHandle.WaitAny()
> This method exposes the functionality associated with the Win32
> call:  ::WaitForMultipleObjectsEx(). This call allows a thread to
> block against a wide variety of objects: semaphores, mutexes,
> threads, events, and so on. If any or all of those objects move to
> the signaled state, then the function returns. POSIX, in my
> experience, has no analog.
>
>
>   When you combine these two together, you wind up in a situation you
> cannot easily replicate under POSIX+BSD sockets. You can use select()
> to monitor a socket for events and pthread_cond_timedwait for the
> condition variable (close and better than Win32 EVENTS). However,
> there is not a pthread_mutex_timedlock for a timeout-able mutex lock
> under Linux.
>   Even if there was, the semantics would still not translate well. If
> you do a System.Threading.WAitHandle.WaitForAny() with a 2ms timeout,
> how do you "share" the timeout among the several different objects?
> It is easy to imagine a situation where you start to divide below the
> timing granularity.
>   Needless to say, the .NET Framework betrays its parentage, and I
> was wondering how people had planned to deal with this under the
> various Unix platforms.
>
> Christian
>
> PS. For the record, Outlook wants to correct the word "IntPtr" with
> "Inept". :)
>
> +-----+
> Christian Ratliff <cratliff@lily.org>
> lily Development Group
> "This is the very perfection of man,
>   to find out his own imperfections" -  St. Augustine
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
>
> iQA/AwUBO/7DnrZBtyfwMNgGEQL8egCgvRQKhGUf2+JymOmMnCxFytYZ8CsAoJt4
> eCRn/7ao+6dvNrOZR3o17oRk
> =OZW5
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Mono-list maillist  -  Mono-list@ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>