Hello, I understand your point and also think that providing a custom runtime can be awkward. I am still working hard to have a clean an acceptable solution to the problem.
The Monobjc 4.0.436 (dylib inside) has solved some crash problems but not all. That makes me say that there are other cases when the bridge is crossed outside the thread management scope of Mono: - the first solution is to identify all theses possible paths (that lead to crash) and forbid them. - the second solution is to provide a patched Mono runtime that do a proper thread management. I need to provide both a short-term and a long-term solution to Monobjc's users. So I am open to any suggestions on how to do it well. Regards, Laurent Etiemble. 2009/12/6 marc hoffman <m...@elitedev.com>: > Am i the only one who thinks this custom runtime thing is not really > acceptable for anyone who wants to - oh, say - *deploy* applications to > regular users who can't/won't just patch their Mono install? what's the > short-term plan for enabling people to actually ship apps based on Monobjc, > and why can't we stick to the unmanaged dylib that can easily be deployed > alongside the app, at least until an official Mono is out that contains these > patches (if that will ever happen)? > > just thinking out loud, here. > > On Dec 2, 2009, at 12:15 AM, Laurent Etiemble wrote: > >> Hello, >> >> Sorry for the late update, but I had some busy nights trying to find >> another work-around for the Snow Leopard crash. The 4.0.436 release of >> the Monobjc bridge has brought mixed results regarding the Snow >> Leopard crash: some users have reported success while others have >> reported nasty crashes. >> >> So, I have resumed my work on the Mono runtime patching to find an >> acceptable way to do it (not too hacky so Novell would accept it). >> During my tests, I have discover that the conditions of the bug are >> already present under Leopard. Why it does not crash seems linked to >> the way TSD (Thread Specfic Data) are destroyed. So I have changed my >> approach and I have come to a workaround that seems to prevent the >> crash. >> >> The archive of the patched Mono runtime is available at: >> http://build.monobjc.net/releases/2.4.2.3_M/MonoFramework-2.4.2.3_M-universal.tar.bz2 >> >> In order to use the archive: >> - you need to have a working installation of Mono. >> - uncompress the archive in /Library/Frameworks/Mono.framework/Versions >> - relink the Current symlink to the archive (sudo rm Current && sudo >> ln -s 2.4.2.3_M Current) >> >> Some points about this runtime: >> - The runtime is universal. I have made some tests under some >> OS/Processor combinations, but I cannot cover all hardware. >> - The runtime contains Mono, Visual Basic and NAnt. It does not >> contains libgdiplus or any of the third-party packages. >> - The runtime contains all what is needed to run mkbundle or the >> packaging tasks. >> - The runtime also contains other patches: embedded "machine.config" >> and "app.config" are now usable. >> >> If you decide to test this runtime, please provide the following: >> - hardware/system full version >> - kind of application/complexity >> - anything that can help in case of crash >> >> Regards, Laurent Etiemble. > >
