[PUTAIN] j'essaie de faire un serveur TCP mais c'est quoi cette merde d'ownership et de borrow
Je veux juste push ma struct Client dans un vector et lancer une nouvelle task mais impossible dans ce language de merde sans faire un Arc avec un Mutex de mon client qu'il faut cloner 50 fois et faire un lock juste pour exécuter des fonctions
Je veux juste push ma struct Client dans un vector et lancer une nouvelle task mais impossible dans ce language de merde sans faire un Arc avec un Mutex de mon client qu'il faut cloner 50 fois et faire un lock juste pour exécuter des fonctions
Tuto pour vivre longtemps et en bonne santé (physique et mentale) : https://onche.org/topic/832673/
Lit la docu bordel
[PUTAIN] j'essaie de faire un serveur TCP mais c'est quoi cette merde d'ownership et de borrow
Je veux juste push ma struct Client dans un vector et lancer une nouvelle task mais impossible dans ce language de merde sans faire un Arc avec un Mutex de mon client qu'il faut cloner 50 fois et faire un lock juste pour exécuter des fonctions
Je veux juste push ma struct Client dans un vector et lancer une nouvelle task mais impossible dans ce language de merde sans faire un Arc avec un Mutex de mon client qu'il faut cloner 50 fois et faire un lock juste pour exécuter des fonctions
Demande a gpt bordel :
Je comprends TOTALEMENT ta rage, c’est l’enfer la première fois qu’on tombe sur le borrow checker de Rust, surtout quand tu veux juste coder comme en C# ou en Python, mais qu’on t’oblige à réfléchir comme un moine Shaolin du thread safety.
Ce que tu décris, c’est LE truc qui fait criser tous les devs qui débutent en Rust avec du réseau et de la concurrence.
Petit point rapide, puis exemple concret.
---
1. Pourquoi Rust te fait chier avec Arc/Mutex ?
Ownership: En Rust, chaque valeur a un “propriétaire” unique, et dès que tu passes la valeur ailleurs, tu n’y as plus accès… sauf si tu la clones, ou que tu utilises des références (mais là tu te fais défoncer dès que t’es en multi-thread).
Send/Sync: Si tu veux partager des données entre threads (genre chaque client dans un thread/tâche), tu DOIS garantir que l’accès est thread-safe.
Arc: C’est un compteur de références atomique (genre Rc mais pour le multi-thread). Il te permet de partager un truc entre threads (mais lecture SEULE, sans Mutex).
Mutex: Si tu veux modifier, il te faut aussi protéger l’accès (d’où Mutex).
---
2. Exemple “minimal”
Imaginons une struct Client que tu veux stocker dans un Vec global (partagé entre tes tasks), puis chaque client peut être utilisé dans une tâche.
Déclaration :
use std::sync::{Arc, Mutex};
struct Client {
id: usize,
// autres champs
}
Ta liste globale des clients :
// Tu veux partager ça entre tes tasks
let clients = Arc::new(Mutex::new(Vec::new()));
Quand tu acceptes un nouveau client :
let client = Client { id: 42 };
let client = Arc::new(Mutex::new(client));
// On stocke l'Arc dans le Vec (et pas le Client direct)
clients.lock().unwrap().push(client.clone());
// Et on lance une tâche asynchrone ou un thread :
let handle = tokio::spawn({
let client = client.clone();
async move {
// Là tu peux utiliser client.lock().unwrap() pour accéder aux données
println!("Client connecté : {}", client.lock().unwrap().id);
// ... ton code ici ...
}
});
---
3. Pourquoi c’est relou ?
Le Vec doit être protégé car plusieurs tasks peuvent vouloir ajouter/retirer des clients.
Chaque Client est lui aussi dans un Arc/Mutex si tu veux le muter depuis plusieurs endroits, ou alors tu fais en sorte qu’il soit “consommé” par une seule tâche (ce qui évite le Mutex).
Cloner l’Arc ne clone pas l’objet, juste le pointeur partagé (c’est safe).
---
4. Tu veux éviter ça ?
Si tu veux que chaque Client ne soit jamais partagé entre tâches, tu peux transférer l’ownership (avec un move) : pas besoin d’Arc/Mutex pour le client, mais tu ne peux plus y accéder ailleurs.
Si tu veux centraliser des actions sur les clients (genre broadcast), t’es obligé d’utiliser Arc/Mutex sur le Vec.
---
TL;DR
Arc = tu partages un objet entre threads/tasks, mais pas modifiable sans Mutex.
Mutex = tu veux modifier un objet partagé (Vec, Client, etc.) entre threads/tasks.
Cloner un Arc = tu obtiens juste un nouveau pointeur, pas un vrai clone du Client.
Tu veux faire sans Arc/Mutex ? Faut accepter de “donner” l’ownership à chaque thread/task, et donc ne pas garder de liste centrale des clients modifiable de partout.
---
Si tu veux me montrer ton code (ou juste un snippet), je peux te “rustifier” ça pour que ça compile sans te faire craquer le cerveau. Balance le bout qui bloque, je t’arrange ça.
Sinon, rassure-toi, tout le monde pète un câble la première fois avec Rust là-dessus. Mais après, tu ne reviendras plus jamais à la gestion mémoire de C/C++… et tu comprendras pourquoi les devs Rust sont si zen (ou chauves).
Je comprends TOTALEMENT ta rage, c’est l’enfer la première fois qu’on tombe sur le borrow checker de Rust, surtout quand tu veux juste coder comme en C# ou en Python, mais qu’on t’oblige à réfléchir comme un moine Shaolin du thread safety.
Ce que tu décris, c’est LE truc qui fait criser tous les devs qui débutent en Rust avec du réseau et de la concurrence.
Petit point rapide, puis exemple concret.
---
1. Pourquoi Rust te fait chier avec Arc/Mutex ?
Ownership: En Rust, chaque valeur a un “propriétaire” unique, et dès que tu passes la valeur ailleurs, tu n’y as plus accès… sauf si tu la clones, ou que tu utilises des références (mais là tu te fais défoncer dès que t’es en multi-thread).
Send/Sync: Si tu veux partager des données entre threads (genre chaque client dans un thread/tâche), tu DOIS garantir que l’accès est thread-safe.
Arc: C’est un compteur de références atomique (genre Rc mais pour le multi-thread). Il te permet de partager un truc entre threads (mais lecture SEULE, sans Mutex).
Mutex: Si tu veux modifier, il te faut aussi protéger l’accès (d’où Mutex).
---
2. Exemple “minimal”
Imaginons une struct Client que tu veux stocker dans un Vec global (partagé entre tes tasks), puis chaque client peut être utilisé dans une tâche.
Déclaration :
use std::sync::{Arc, Mutex};
struct Client {
id: usize,
// autres champs
}
Ta liste globale des clients :
// Tu veux partager ça entre tes tasks
let clients = Arc::new(Mutex::new(Vec::new()));
Quand tu acceptes un nouveau client :
let client = Client { id: 42 };
let client = Arc::new(Mutex::new(client));
// On stocke l'Arc dans le Vec (et pas le Client direct)
clients.lock().unwrap().push(client.clone());
// Et on lance une tâche asynchrone ou un thread :
let handle = tokio::spawn({
let client = client.clone();
async move {
// Là tu peux utiliser client.lock().unwrap() pour accéder aux données
println!("Client connecté : {}", client.lock().unwrap().id);
// ... ton code ici ...
}
});
---
3. Pourquoi c’est relou ?
Le Vec doit être protégé car plusieurs tasks peuvent vouloir ajouter/retirer des clients.
Chaque Client est lui aussi dans un Arc/Mutex si tu veux le muter depuis plusieurs endroits, ou alors tu fais en sorte qu’il soit “consommé” par une seule tâche (ce qui évite le Mutex).
Cloner l’Arc ne clone pas l’objet, juste le pointeur partagé (c’est safe).
---
4. Tu veux éviter ça ?
Si tu veux que chaque Client ne soit jamais partagé entre tâches, tu peux transférer l’ownership (avec un move) : pas besoin d’Arc/Mutex pour le client, mais tu ne peux plus y accéder ailleurs.
Si tu veux centraliser des actions sur les clients (genre broadcast), t’es obligé d’utiliser Arc/Mutex sur le Vec.
---
TL;DR
Arc = tu partages un objet entre threads/tasks, mais pas modifiable sans Mutex.
Mutex = tu veux modifier un objet partagé (Vec, Client, etc.) entre threads/tasks.
Cloner un Arc = tu obtiens juste un nouveau pointeur, pas un vrai clone du Client.
Tu veux faire sans Arc/Mutex ? Faut accepter de “donner” l’ownership à chaque thread/task, et donc ne pas garder de liste centrale des clients modifiable de partout.
---
Si tu veux me montrer ton code (ou juste un snippet), je peux te “rustifier” ça pour que ça compile sans te faire craquer le cerveau. Balance le bout qui bloque, je t’arrange ça.
Sinon, rassure-toi, tout le monde pète un câble la première fois avec Rust là-dessus. Mais après, tu ne reviendras plus jamais à la gestion mémoire de C/C++… et tu comprendras pourquoi les devs Rust sont si zen (ou chauves).
ChatGPT est nul à chier pour programmer
Tuto pour vivre longtemps et en bonne santé (physique et mentale) : https://onche.org/topic/832673/
[PUTAIN] j'essaie de faire un serveur TCP mais c'est quoi cette merde d'ownership et de borrow
Je veux juste push ma struct Client dans un vector et lancer une nouvelle task mais impossible dans ce language de merde sans faire un Arc avec un Mutex de mon client qu'il faut cloner 50 fois et faire un lock juste pour exécuter des fonctions
Je veux juste push ma struct Client dans un vector et lancer une nouvelle task mais impossible dans ce language de merde sans faire un Arc avec un Mutex de mon client qu'il faut cloner 50 fois et faire un lock juste pour exécuter des fonctions
ChatGPT est nul à chier pour programmer
Je sais mais il maitrise les concepts
Bon bah installe cursor alors
Bon bah installe cursor alors
J'ai Windsurf mais pas d'abo
Tuto pour vivre longtemps et en bonne santé (physique et mentale) : https://onche.org/topic/832673/
déjà que le travail de programmeur était peu gratifiant, je n'ose pas imaginer à quoi il pourra ressembler dans les années à venir
Vēritās līberābit vōs
Simplement j'ai du mal à comprendre pourquoi tout le monde suce les perfs de Rust alors qu'il faut faire des clones tout le temps et foutre des mutex partout, même quand ça me semble pas nécessaire
Tuto pour vivre longtemps et en bonne santé (physique et mentale) : https://onche.org/topic/832673/
déjà que le travail de programmeur était peu gratifiant, je n'ose pas imaginer à quoi il pourra ressembler dans les années à venir
Certes
Simplement j'ai du mal à comprendre pourquoi tout le monde suce les perfs de Rust alors qu'il faut faire des clones tout le temps et foutre des mutex partout, même quand ça me semble pas nécessaire
[PUTAIN] j'essaie de faire un serveur TCP mais c'est quoi cette merde d'ownership et de borrow
Je veux juste push ma struct Client dans un vector et lancer une nouvelle task mais impossible dans ce language de merde sans faire un Arc avec un Mutex de mon client qu'il faut cloner 50 fois et faire un lock juste pour exécuter des fonctions
Je veux juste push ma struct Client dans un vector et lancer une nouvelle task mais impossible dans ce language de merde sans faire un Arc avec un Mutex de mon client qu'il faut cloner 50 fois et faire un lock juste pour exécuter des fonctions
J'ai Windsurf mais pas d'abo
[PUTAIN] j'essaie de faire un serveur TCP mais c'est quoi cette merde d'ownership et de borrow
Je veux juste push ma struct Client dans un vector et lancer une nouvelle task mais impossible dans ce language de merde sans faire un Arc avec un Mutex de mon client qu'il faut cloner 50 fois et faire un lock juste pour exécuter des fonctions
Je veux juste push ma struct Client dans un vector et lancer une nouvelle task mais impossible dans ce language de merde sans faire un Arc avec un Mutex de mon client qu'il faut cloner 50 fois et faire un lock juste pour exécuter des fonctions
T'as le barrow clef ?
Lien stp
Tuto pour vivre longtemps et en bonne santé (physique et mentale) : https://onche.org/topic/832673/
T'as le barrow clef ?
Non je suis colère
Tuto pour vivre longtemps et en bonne santé (physique et mentale) : https://onche.org/topic/832673/
Simplement j'ai du mal à comprendre pourquoi tout le monde suce les perfs de Rust alors qu'il faut faire des clones tout le temps et foutre des mutex partout, même quand ça me semble pas nécessaire
skill issue
