Sui sistemi Unix, perché dobbiamo esplicitamente file `open ()` e `close ()` per poterli leggere () `o` scrivere () `?

Perché esiste open()ed close()esiste nella progettazione del filesystem Unix?

Il sistema operativo non è in grado di rilevare la prima volta read()o è write()stato chiamato e fare qualsiasi cosa open()normalmente farebbe?

Dennis Ritchie cita nel «L'evoluzione del Unix time-sharing di sistema» che opene closeinsieme read, writee createrano presenti nel sistema giusto fin dall'inizio.

Immagino che un sistema senza opene closenon sarebbe inconcepibile, tuttavia credo che complicherebbe il design. In genere si desidera effettuare più chiamate di lettura e scrittura, non solo una, e questo era probabilmente vero soprattutto su quei vecchi computer con RAM molto limitata su cui aveva origine UNIX. Avere un handle che mantiene la posizione del file corrente semplifica questo. Se readowritedovevano restituire la maniglia, avrebbero dovuto restituire una coppia - una maniglia e il loro stato di restituzione. La parte handle della coppia sarebbe inutile per tutte le altre chiamate, il che renderebbe scomodo tale accordo. Lasciare lo stato del cursore sul kernel consente di migliorare l'efficienza non solo mediante buffering. C'è anche qualche costo associato alla ricerca del percorso: avere un handle ti consente di pagarlo solo una volta. Inoltre, alcuni file nella visione del mondo UNIX non hanno nemmeno un percorso di filesystem (o no - ora lo fanno con cose del genere /proc/self/fd).

Quindi tutte le chiamate reade writedovrebbero passare queste informazioni su ogni operazione:

• il nome del file
• le autorizzazioni del file
• se il chiamante sta aggiungendo o creando
• se il chiamante ha finito di lavorare con il file (per scartare i buffer di lettura inutilizzati e assicurarsi che i buffer di scrittura abbiano veramente finito di scrivere)

Se si considerano le indipendenti chiamate open , read, writee closeper essere più semplice di un singolo-purpose di I / O messaggio è basato sulla vostra filosofia progettuale. Gli sviluppatori di Unix hanno scelto di utilizzare semplici operazioni e programmi che possono essere combinati in molti modi, piuttosto che un'unica operazione (o programma) che fa tutto.

Il concetto di handle di file è importante a causa della scelta progettuale di UNIX secondo cui "tutto è un file", comprese le cose che non fanno parte del filesystem. Come unità a nastro, tastiera e schermo (o teletipo!), Lettori di schede / nastri perforati, connessioni seriali, connessioni di rete e (l'invenzione chiave UNIX) connessioni dirette ad altri programmi chiamati "pipe".

Se guardi molte delle semplici utility UNIX standard come grep, specialmente nelle loro versioni originali, noterai che non includono chiamate a open()e close()ma solo reade write. Gli handle di file vengono impostati all'esterno del programma dalla shell e passati all'avvio. Quindi il programma non deve preoccuparsi se sta scrivendo su un file o su un altro programma.

Così come open, gli altri modi di ottenere descrittori di file sono socket, listen, pipe, dup, e un meccanismo di Heath Robinson per l'invio di descrittori di file su tubi: https://stackoverflow.com/questions/28003921/sending-file-descriptor-by-linux -socket

Modifica: alcune note di lezione che descrivono i livelli di riferimento indiretto e come questo fa funzionare O_APPEND in modo sensato. Tenere presente che la conservazione dei dati degli inode garantisce che il sistema non debba andare e recuperarli nuovamente per la successiva operazione di scrittura.

La risposta è no, perché open () e close () creano e distruggono un handle, rispettivamente. Ci sono momenti (beh, sempre, davvero) in cui potresti voler garantire di essere l'unico chiamante con un determinato livello di accesso, poiché un altro chiamante (ad esempio) che scrive su un file che stai analizzando inaspettatamente potrebbe lasciare un'applicazione in uno stato sconosciuto o portare a un livelock o deadlock, ad esempio il lemma dei filosofi da pranzo.

Anche senza quella considerazione, ci sono implicazioni sulle prestazioni da considerare; close () consente al filesystem di (se è appropriato o se lo hai richiesto) svuotare il buffer che stavi occupando, un'operazione costosa. Diverse modifiche consecutive a un flusso in memoria sono molto più efficienti di diversi cicli di modifica lettura / scrittura essenzialmente non correlati a un filesystem che, per quanto ne sai, esiste a metà mondo sparpagliato su un data center di archiviazione di massa ad alta latenza. Anche con l'archiviazione locale, la memoria è in genere molti ordini di grandezza più veloce dell'archiviazione di massa.

Open () offre un modo per bloccare i file mentre sono in uso. Se i file venissero aperti, letti / scritti automaticamente e quindi richiusi dal sistema operativo, non vi sarebbe nulla che impedisse ad altre applicazioni di modificare tali file tra le operazioni.

Sebbene ciò possa essere gestibile (molti sistemi supportano l'accesso ai file non esclusivo) per semplicità la maggior parte delle applicazioni presume che i file aperti non cambino.

Perché il percorso del file potrebbe spostarsi mentre stai assumendo che rimarrà lo stesso.

La lettura e la scrittura su un filesystem può comportare una grande varietà di schemi di buffering, pulizia del sistema operativo, gestione del disco di basso livello e una serie di altre potenziali azioni. Quindi le azioni open()e close()fungono da set-up per questi tipi di attività sottocoperta. Diverse implementazioni di un filesystem potrebbero essere altamente personalizzate secondo necessità e rimanere comunque trasparenti al programma chiamante.

Se il sistema operativo non avesse apertura / chiusura, quindi con reado write, quelle azioni sui file dovrebbero comunque eseguire qualsiasi inizializzazione, svuotamento / gestione del buffer, ecc. Ogni volta. È un sacco di spese generali da imporre per letture e scritture ripetitive.

Il mantra Unix è "offrire un modo di fare le cose", che significa "factoring" in pezzi (riutilizzabili) da combinare a piacimento. Vale a dire, in questo caso, separare la creazione e la distruzione degli handle di file dal loro uso. Importanti vantaggi sono arrivati ​​in seguito, con pipe e connessioni di rete (sono anche manipolati tramite handle di file, ma sono creati in altri modi). Essere in grado di spedire handle di file in giro (ad es. Passandoli a processi figlio come "file aperti" che sopravvivono exec(2)e persino a processi non correlati attraverso una pipe) sono possibili solo in questo modo. Soprattutto se si desidera offrire un accesso controllato a un file protetto. Quindi puoi ad es. Aprire/etc/passwd per la scrittura e passalo a un processo figlio a cui non è consentito aprire quel file per la scrittura (sì, lo so che questo è un esempio ridicolo, sentiti libero di modificarlo con qualcosa di più realistico).