Dans .NET, la pile d'appels est-elle inextricablement liée à un thread?

Question

Est-il tout à fait possible au milieu d'une exécution de fonction de définir un pointeur sur la pile en cours (à récupérer ultérieurement), puis de libérer le thread actuel (sans dérouler la pile d'appels) et de le renvoyer au pool de threads ? Et puis, un autre fil reprendra-t-il là où ce fil s'est arrêté? Je sais que cela signifierait que quelqu'un appelant dans la fonction ne saurait pas que le contexte du thread actuel aurait changé, et cela impliquerait probablement d'écrire du code IL personnalisé pour faire quelque chose comme ça, mais y a-t-il une façon de faire?

Answer 1

Non, une pile fait partie de l'état d'un thread. Vous pouvez utiliser des workflows asynchrones pour faire ce genre de chose (et le CCR rend cela plus facile) mais vous ne pouvez pas simplement renvoyer le thread au pool de threads.

Vous pourriez écrire un pool de threads que a fait pour ce faire, mais ce serait une mauvaise idée IMO - ce serait l'équivalent du pool de threads d'appeler Application.DoEvents IMO.

Answer 2

Ce que vous décrivez est des suites délimitées. Malheureusement, le CLR n'a aucun support pour cela, et ne peut pas être implémenté en code managé (pas même en code mixte) avec des trucs que je connais.

Actuellement, j'ai besoin de cette fonctionnalité dans IronScheme. Il existe des moyens de créer ce type de fonctionnalité sur le CLR, en écrivant un compilateur qui effectue une conversion CPS, mais qui provoque une série de problèmes d'interopérabilité (vous ne pouvez pas appeler les fonctions .NET directement, etc.).

J'ai fait quelques expériences avec la conversion CPS dans IronScheme, mais mon compilateur actuel n'est pas vraiment adapté pour cela, et fonctionne plutôt lentement.