atom feed15 messages in org.freebsd.freebsd-threadsMono's XSP crashes on browser connection
FromSent OnAttachments
Tom McLaughlinFeb 28, 2005 2:46 am 
Tom McLaughlinMar 2, 2005 5:40 am 
David XuMar 2, 2005 11:18 pm 
Daniel EischenMar 2, 2005 11:58 pm 
Tom McLaughlinMar 3, 2005 7:04 am 
Jeremy MessengerMar 3, 2005 7:13 am 
David XuMar 3, 2005 7:16 am 
Tom McLaughlinMar 3, 2005 7:35 am 
David XuMar 3, 2005 2:32 pm 
Craig RodriguesMar 3, 2005 3:15 pm 
Jeremy MessengerMar 3, 2005 7:01 pm 
Craig RodriguesMar 3, 2005 7:18 pm 
Jeremy MessengerMar 3, 2005 7:24 pm 
David XuMar 3, 2005 11:36 pm 
Tom McLaughlinMar 4, 2005 5:24 am 
Subject:Mono's XSP crashes on browser connection
From:Jeremy Messenger (mez@cox.net)
Date:Mar 3, 2005 7:01:17 pm
List:org.freebsd.freebsd-threads

On Thu, 3 Mar 2005 10:15:44 -0500, Craig Rodrigues <rodr@crodrigues.org> wrote:

On Thu, Mar 03, 2005 at 10:32:41PM +0800, David Xu wrote:

whether _POSIX_THREAD_PROCESS_SHARED is defined or not in source code, but he failed to respect this macro at many places, so the macro is rather bogus.

David, thanks for dig it deeper!

Side note:

Keep in mind, that according to the POSIX/Single Unix Specification standards, if a _POSIX_* macro is defined, but is -1, that means that the feature is unsupported. ( See: http://www.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html ).

We define a lot of POSIX macros like this in <unistd.h>.

Do you need anyone to test your ttyname_r patch? I can try to test it with mono here on RELENG_5 and see how it goes. I don't know ttyname_r that much, but I can dig in web/google.

Cheers, Mezz

The convention on Linux's glibc is to only define a _POSIX macro if the feature is supported. Consequently, a lot of software written on Linux which assumes this convention will break on FreeBSD.

The Linux glibc convention is IMHO more intuitive, but FreeBSD is more "standards" conformant.

So the Mono code is not entirely doing the right thing with respect to checking _POSIX_THREAD_PROCESS_SHARED....but you mention that the Mono code isn't even consistent in checking this macro. Bleh. :)