Non, c'est lié à la notion de scope, quand ton mutex sort du scope c'est libéré et tu ne peux plus accéder, sachant que tu vas vite spontanément créer un scope au moment ou tu vérouilles le mutex (le langage t'y pousse).
Il y a toujours besoin de faire gaffe sur les questions de mutex, Rust va t'éviter certaines classes d'erreurs (du double accès en même temps), mais va pas beaucoup aider sur d'autres. Typiquement dans ton exemple de code, tu pourrais avoir syntaxiquement un accès ensuite à data, certe completement inaccessible en pratique mais c'est sans doute théoriquement indécidable (on n'est quand même pas loin du problème de l'arrêt). De même si tu as 2 mutex, il va pas pouvoir te garantir que tu n'as pas de deadlock, mais le langage va te pousser à n'avoir qu'un mutex et une struct dedans.
Y'a un verrouillage complet de la mémoire? Y'a pas un autre processus qui pourrait venir y fourrer nez comme par exemple un gdb? Ou le même processus mais qui est dans la partie en C? Ou un petit firmware proprio qu'on a du charger sur lequel on a pas le contrôle.
Pas un verrouillage, le compilateur va te garantir que ton code rust n'y met pas son grain de sel (et encore, tu peux surrement le contourner avec qq unsafe bien placé), pas que le reste du monde ne va pas le faire. Donc oui, une dépendance qui appelle un autre langage va permettre d'en sortir, un driver va pouvoir y accéder. Ce n'est pas du tout une protection cryptographique.
Pour moi, un des gros points d'interet de Rust est justement d'avoir réussi à construire une sorte d'entre deux entre garbage collector et tu manages ta mémoire. Cet entre deux n'est possible que parce que le langage t'impose des restrictions sur ce que tu peux faire (les règles d'ownership). Ces restrictions empechent pleins de programmes correctes de compiler mais permettent au compilateur de décider si et quand la mémoire peut être libérée ou est vérouillée. Les problèmes d'analyse de code tombe vite dans de l'indécidable dans le cas général, mais justement le langage n'est pas un cas général du fait des restrictions imposées. Ils ont réussi à relacher certaines restrictions, mais ne pourront sans doute jamais toutes les lever.
Sur le threading, je trouve le compromis pas aussi excellent que sur la gestion de la mémoire, on enlève certaines classes d'erreurs mais il en reste beaucoup, peut être qu'on trouvera mieux, et je trouve que "fearless concurrency" est trop marketing par rapport à la réalité, "lesser concurrency fear" serait plus réaliste
[^] # Re: mode Brice on
Posté par Fulgrim . En réponse au journal Linus répond à la controverse sur R4L (Rust pour Linux). Évalué à 4.
Non, c'est lié à la notion de scope, quand ton mutex sort du scope c'est libéré et tu ne peux plus accéder, sachant que tu vas vite spontanément créer un scope au moment ou tu vérouilles le mutex (le langage t'y pousse).
Il y a toujours besoin de faire gaffe sur les questions de mutex, Rust va t'éviter certaines classes d'erreurs (du double accès en même temps), mais va pas beaucoup aider sur d'autres. Typiquement dans ton exemple de code, tu pourrais avoir syntaxiquement un accès ensuite à data, certe completement inaccessible en pratique mais c'est sans doute théoriquement indécidable (on n'est quand même pas loin du problème de l'arrêt). De même si tu as 2 mutex, il va pas pouvoir te garantir que tu n'as pas de deadlock, mais le langage va te pousser à n'avoir qu'un mutex et une struct dedans.
Pas un verrouillage, le compilateur va te garantir que ton code rust n'y met pas son grain de sel (et encore, tu peux surrement le contourner avec qq unsafe bien placé), pas que le reste du monde ne va pas le faire. Donc oui, une dépendance qui appelle un autre langage va permettre d'en sortir, un driver va pouvoir y accéder. Ce n'est pas du tout une protection cryptographique.
Pour moi, un des gros points d'interet de Rust est justement d'avoir réussi à construire une sorte d'entre deux entre garbage collector et tu manages ta mémoire. Cet entre deux n'est possible que parce que le langage t'impose des restrictions sur ce que tu peux faire (les règles d'ownership). Ces restrictions empechent pleins de programmes correctes de compiler mais permettent au compilateur de décider si et quand la mémoire peut être libérée ou est vérouillée. Les problèmes d'analyse de code tombe vite dans de l'indécidable dans le cas général, mais justement le langage n'est pas un cas général du fait des restrictions imposées. Ils ont réussi à relacher certaines restrictions, mais ne pourront sans doute jamais toutes les lever.
Sur le threading, je trouve le compromis pas aussi excellent que sur la gestion de la mémoire, on enlève certaines classes d'erreurs mais il en reste beaucoup, peut être qu'on trouvera mieux, et je trouve que "fearless concurrency" est trop marketing par rapport à la réalité, "lesser concurrency fear" serait plus réaliste