Ruby File.open e a necessidade de f.close

É de conhecimento comum na maioria das linguagens de programação que o stream para trabalhar com arquivos é open-use-close. No entanto, eu vi muitas vezes em códigos Ruby chamadas File.open incomparáveis, e além disso eu encontrei esta jóia de conhecimento nos docs ruby:

Os streams de E / S são fechados automaticamente quando são reivindicados pelo coletor de lixo.

darkredandyellow friendly irc assumir a questão:
[17:12] sim, e também, o número de descritores de arquivos é geralmente limitado pelo SO
[17:29] Eu suponho que você pode facilmente ficar sem descritores de arquivos disponíveis antes do coletor de lixo limpar. Nesse caso, você pode querer usá-las por conta própria. “reivindicado pelo coletor de lixo.” significa que o GC atua em algum momento no futuro. e é caro. muitas razões para fechar arquivos explicitamente.

  1. Precisamos fechar explicitamente
  2. Se sim, por que o autoclose do GC?
  3. Se não, então por que a opção?

Eu vi muitas vezes em códigos Ruby incomparáveis ​​chamadas File.open

Você pode dar um exemplo? Eu só vejo isso no código escrito por novatos que não têm o “conhecimento comum na maioria das linguagens de programação que o stream para trabalhar com arquivos é open-use-close”.

Rubistas experientes fecham explicitamente seus arquivos ou, de forma mais idiomática, usam o formato de bloco de File.open , que automaticamente fecha o arquivo para você. Sua implementação basicamente parece algo como isto:

 def File.open(*args, &block) return open_with_block(*args, &block) if block_given? open_without_block(*args) end def File.open_without_block(*args) # do whatever ... end def File.open_with_block(*args) yield f = open_without_block(*args) ensure f.close end 

Scripts são um caso especial. Os scripts geralmente são muito curtos e usam tão poucos descritores de arquivos que simplesmente não faz sentido fechá-los, já que o sistema operacional os fechará assim mesmo quando o script sair.

Precisamos fechar explicitamente?

Sim.

Se sim, por que o autoclose do GC?

Como depois de coletar o object, não há como você fechar o arquivo e, portanto, vazaria descritores de arquivo.

Observe que não é o coletor de lixo que fecha os arquivos. O coletor de lixo simplesmente executa qualquer finalizador para um object antes de coletá-lo. Acontece que a class File define um finalizador que fecha o arquivo.

Se não, então por que a opção?

Porque a memory desperdiçada é barata, mas os descritores de arquivos desperdiçados não são. Portanto, não faz sentido amarrar o tempo de vida de um descritor de arquivo ao tempo de vida de algum fragment de memory.

Você simplesmente não pode prever quando o coletor de lixo será executado. Você não pode nem mesmo prever se ele será executado: se você nunca ficar sem memory, o coletor de lixo nunca será executado, portanto, o finalizador nunca será executado, portanto, o arquivo nunca será fechado.

Você deve sempre fechar os descritores de arquivo após o uso, que também irá liberá-lo. Geralmente, as pessoas usam File.open ou método equivalente com blocos para manipular o tempo de vida do descritor de arquivo. Por exemplo:

 File.open('foo', 'w') do |f| f.write "bar" end 

Nesse exemplo, o arquivo é fechado automaticamente.

  1. sim
  2. Caso contrário, ou se houver algum outro fracasso
  3. Veja 2.

De acordo com http://ruby-doc.org/core-2.1.4/File.html#method-c-open

Sem nenhum bloco associado, File.open é sinônimo de :: new. Se o bloco de código opcional for fornecido, ele será transmitido como um argumento e o object File será fechado automaticamente quando o bloqueio for finalizado. O valor do bloco será retornado de File.open.

Portanto, será fechado automaticamente quando o bloqueio terminar : D

Podemos usar a function File.read() para ler o arquivo em ruby ​​….. como

 file_variable = File.read("index.html") 

neste exemplo file_variable pode ter o valor total desse arquivo ….