Laurent, > 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.
me, im perfectly happy with the dylib solution, if that can fix all the issues. if later on official Mono distros will get fixes that make the dylib obsolete - great. but until then. i'd prefer needing the dylib to needing a custom Mono runtime, a thousand-fold. the dylib is pretty much a non-issue. Apps get .app-bundled anyways, so copying two more files is a no-brainer (especially if MacPac does it for you). needing a custom runtime to test and debug Monobjc aps is a real showstopper for us telling our customers to use Monobjc (and mkbundle - all comments for or against it, aside - only helps with final deployment. the developer (our customer ;) still needs the custom runtime, which will get confusing and problematic, once newer Mono's come out (as the one that just did, which is a critically important update that users wot wanna skip). so my vote is on keeping the dylib, until such time that we can make do entirely without it, on a new vanilla Mono. hth, marc > 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. >> >>
