Mono 1.0.5 support for NetBSD 2.0

As I promised earlier, here is the patch for Mono 1.0.5 to run on NetBSD 2.0-Release.

I've managed to get MonoDoc 1.0.5 to run on my box and near being able to run MonoDevelop too. It seems that somewhere, a mutex is unlocked twice and since the libpthread is asserting on that kind of invalid behavior, MonoDevelop stops. But even if assertions are disabled, MonoDevelop stops while not being able to read a perfectly valid file... Well :) There's some work to be done here.

Earlier I talked about the fact that I forgot to save the stack's address of suspended threads. Under Linux, where signals are used to "suspend" threads, the signal handler looks like this :

   void GC_suspend_handler(int sig)
   {
      int dummy;

      /* some not important stuff... */

      pthread_t my_thread = pthread_self();

      me -> stop_info.stack_ptr = (ptr_t)(&dummy);  /* Get the top of the stack address */

      sigsuspend(&suspend_handler_mask); /* Wait for signal to resume */
   }

The thread being stopped is held into its signal handler, waiting for the signal to resume and exit the signal handler. The main reason for this "trick" is that there is no standard way to suspend a thread with the libpthread.

However, NetBSD's libpthread has two nice methods pthread_suspend_np and pthread_resume_np, which are able to suspend and resume arbitrarily a specific thread. So in the GC code, instead of raising signals to specific threads, calling these two methods is only necessary.

The thing I missed in the first patch, is the storage of the top stack's address, retreived by using the dummy variable in the signal handler. So, to work around this problem, I used a third non standard function that is able to retreive the base adress, not the top address, of the stack for the suspended thread and give it to the GC.

Although, the patch seems to please mono, which is running fine, the stack address given to the GC is not the perfect one. Unfortunately, there is no way, as far as I know, to get the top of stack pointer for suspended threads. I can't tell for now the impact of this modification, but still, mono does not seem to complain, neither does the GC.

I also tried to mix signals and thread suspension, but it seems that signals in general are breaking GC's operations.

Maybe some pthread/GC guru could enlighten me :)

Update : It also works nicely with Mono 1.1.3. Actually, it runs better as it has a little bug that has been fixed in System.Timers.Timer, but this has nothing to do with NetBSD ;)

Publié mercredi 15 décembre 2004 21:18 par jay
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Commentaires


Les 10 derniers blogs postés

- Un grand SharePointeur nous a quitte : Patrick Tisseghem manquera à la communauté ! par RedoBlog - The .NET Gentleman !!! le il y a quelques secondes

- [WPF] Comment charger dynamiquement un fichier XAML qui définit des eventhandler ? par Thomas Lebrun le il y a 21 heures et 57 minutes

- Article sur le filtrage des modèles de site SharePoint par The Grib's Lair [Sébastien PICAMELOT - MVP SharePoint] le 09-04-2008, 00:11

- Adopter votre Redo en 3D - Clone Virtuel - avec photosynth par RedoBlog - The .NET Gentleman !!! le 09-04-2008, 00:07

- [Expression Web] Astuce de la Semaine : Mettre en bouton ses macros dans une barre d'outils. par Expression Web & Me le 09-03-2008, 20:48

- [.Net] Présentation du Client Profile par Elise's blog le 09-03-2008, 12:28

- SharePoint : Test de Chrome avec SharePoint 2007 (MOSS et WSS) par Blog Technique de Romelard Fabrice le 09-03-2008, 11:38

- Google Chrome : Faille de Sécurité ?!? par The diary of EBArtSoft le 09-03-2008, 11:35

- ASP.net - tout savoir sur la validation des entrées utilisateurs | les controles de validation par Atteint de JavaScriptite Aiguë [Cyril Durand] le 09-02-2008, 23:43

- Google Chrome J'adopte ! par The diary of EBArtSoft le 09-02-2008, 21:36