Tra il codice e la realtà

In un progetto sul quale ho lavorato di recente, mi è capitato di avere a che fare con flussi (streaming multimediali) a bitrate relativamente alto, per l’hw in questione. Scrivo questo post perché siamo stati vittime di un nostro (banale) bug che ci è costato qualche giorno di test e qualche mal di testa: magari qualcuno potrà evitarseli leggendo questo post… non si trova molta documentazione in giro.

Intanto qualche altro dettaglio sul sistema: un client che riceve flussi multimediali in UDP (fino a 10 mbs) su windows embedded ce 6.0, realizzato in c++ con il visual studio 2005, utilizzando direttamente winsock2. Un thread si occupa della ricezione utilizzando semplicemente una socket in modalità bloccante in un ciclo di lettura che ha anche il compito di effetture alcune operazioni sui dati (poco onerose in termini di CPU) e di copiarli in un buffer dal quale un thread consumatore le preleva. Viene utilizzata la funzione recv(), visto che la modalità bloccante non è affatto un problema (e quindi l’ overlapped I/O è inutile) e le completion routine non sono ben supportate da windows embedded ce 6.0.

Tutto sembra funzionare bene, fino a bitrare inferiori a 2 mbs, ma superando tale valore… si manifestano degli strani problemi. Dopo molta fatica (visto che ovviamente non era possibile andare in debug, ma neppure scrivere su file se non pochi kbytes e quidi il debug stesso non poteva che avvenire anch’esso via rete), sembrava inequivocabile che si trattasse di perdite di pacchetti dallo 0.3% al 3% circa. A ridurre la nostra lucità di analisi si metteva anche il fatto che ad avere problema era solo uno streamer che utilizzavamo per la prima volta, mentre quello che avevamo utilizzato fino ad allora funzionava alla grande (ora sappiamo che dipendeva solo dal bitrate).

Il passo successivo (e molto poco divertente) è stato quello di usare wireshark per verificare se una tale perdita di pacchetti era in qualche modo imputabile alla nostra lettura… provate a cercare in un dump 1 paccheto perso, verificando che non ci siano buchi in un continuity counter a 4 bit e con il parser di wireshark bacato. Davvero poco divertente. Comunque le perdite non c’erano!

Il problema è semplicemente legato al fatto che il sistema operativo allocca un buffer interno, settato di defaut a pochi kbytes, che può facilmente venire saturato se il thread che effettua la lettura non è sufficientemente veloce o se viene sospeso (anche solo per pochi ms).

Fortunatamnte la soluzione esiste: basta settare un buffer di ricezione più grande.

unsigned bufferSize = 1024 * 1024;
::setsockopt(s_, SOL_SOCKET, SO_RCVBUF, (const char FAR*)&bufferSize, sizeof(bufferSize));

con 1 mbyte di buffer, a 10 mbs, si possono gestire circa 800 ms di flusso: si tratta di un valore congruo che ci ha permesso di eliminare del tutto le perdite.

Una poco velata critica al C++ da parte di Linus Torvalds, mi ha portato a fare qualche considerazione sul C++ e più in generale sulle motivazioni delle scelte (apparentemente solo di natura tecnica) dei programmatori.

Devo premettere che sono di parte, visto che da molti anni utilizzo (con soddisfazione) principalmente il C++. D’altro canto ho comunque avuto a che fare nel corso degli anni con altri linguaggi, ambienti e procedure di sviluppo, in progetti molto diversi per numero di partecipanti, complessità e obbiettivi. Spero quindi di poter fare delle considerazioni non partigiane…. 🙂

Fondamentalmente io non concordo con Torvalds, ma paradossalmente concordo per certi versi con lui quando dice

I've come to the conclusion that any programmer that would prefer the project to be
in C++ over C is likely a programmer that I really *would* prefer to piss
off, so that he doesn't come and screw up any project I'm involved with.

Semplicemente io non vorrei assolutamente nessun programmatore nel mio team che preferisse un qualsiasi linguaggio (ma anche tool o sistema operativo), in modo INCONDIZIONATO, non relazionato agli obbiettivi del progetto.

Questo non vuol dire affatto che la scelta non debba dipendere ANCHE dalle proprie inclinazioni personali o quanto meno dal proprio patrimonio di conoscenze (stando attenti a non infilarsi nelle profezie auto-avveranti di Carlo Pescio). Vuol dire semplicemente e molto banalmente che la scelta di un linguaggio, un tool o una metodologia da utilizzare deve dipendere dagli obbiettivi di progetto e non da valori pure apparentemente validi in generale.

Più in generale si tratta di una forma di dis-allineamento tra i VALORI del progetto (spesso ad esempio i tempi di rilascio) e quelli ritenuti tali dagli sviluppatori (efficienza, scalabilità, ma anche documentazione, copertura dei test di unità etc). E’ vero che spesso non è affatto facile capire quali siano i valori del progetto (anche per responsabilità del menagement) e che non è certo compito degli sviluppatori definirli, ma è sicuramente loro compito comprenderli e lavorare onestamente al fine di massimizzarli.

L’errore più comune è quello di scambiare strumenti con obbiettivi: un programma deve fare senza errori quello che gli utenti si aspettano, non avere la barra verde dei test unità sulla macchina degli sviluppatori. O aprossimarli con valori considerati sempre validi: ad esempio le prestazioni (cosa spesso non utile o magari da ricercare su piani molto diversi dell’ottimizzazione delle strutture base) o la flessibilità che viene intesa in termini estremamente tecnici (come magari la molto remota possibilità di utilizzare db server differenti), mentre ciò che sarebbe veramente utile è la flossibilità di reagire a cambiamenti delle spicifiche.

La cosa più interessante è che, paradossalmente, questi “errori di prospettiva” sono possibili SOLO a programmatori che abbiano un discreto grado di conoscenze e anche una certa dose di passione e che quindi potrebbero anche essere considerati dei buoni programmatori. Sicuramente però sarebbero dei pessimi team leader, quelli che Carlo Pescio chiama super-programmatori e che sono ottimi per portare a compimento il progetto che esiste nella loro mente (non quello che gli viene affidato).

In questo senso è più probabile che un super-programmatore usi il C++ piuttosto che il C ? Probabilmente sì, visto che è assolutamnete coerente con la sua psicologia utilizzare lo strumento più avanzato, innovativo e “potente” (qualsiasi cosa voglia dire). Ma a dire il vero (e per le stesse motivazioni) è più probabile che usi Java (o magari Ruby o Python) e che sia un patito di linux, dell’open source e soprattutto dell’extreme programming.

Nel merito delle caratteristiche tecniche del C++ rispetto al C o ad altri linguaggi invece è meglio che parli in un altro post… questo è già troppo lungo così 🙂