CODEWITHSUNDEEP
ruby-on-railsruby
cakeforcerberus
cakeforcerberus

Reputation: 4657

Does ruby IO.read() lock?

I have a webservice method that reads a photo and returns its byte data. I'm currently doing the following:

@photo_bytes = IO.read("/path/to/file")
send_data(@photo_bytes, :filename => "filename", :type => "filetype", :disposition => "inline")

I'm getting some strange behavior when calling this a lot... occasionally send_data is returning null. I'm thinking that maybe I'm getting read contention if a file hasn't been closed yet. Do I need to explicitly close the file after opening it with IO.read? How could I use read_nonblock to do this and would it be worth it?

UPDATE:

So I did some more logging and occasionally IO.read is returning a value like 1800 bytes when it usually returns ~5800 bytes for a picture. When it return 1800 bytes the picture does not show up on the client. This happens fairly randomly when two users are calling the web service.

Thanks

Tom

Upvotes: 3

Views: 876

Answers (1)

rcoder
rcoder

Reputation: 12829

The IO.read method doesn't do any advisory file locking, and so shouldn't be affected by other concurrent readers. However, if you have code elsewhere in your application which writes to the same path, you need to make sure you update the file atomically. Opening a file in write (not append) mode immediately truncates the file to zero bytes, so until the new version had been written, you could well see empty responses generated from the above snippet.

Assuming you're on a *NIX platform like Linux or OS X, though, you can update a file atomically using code like this:

require 'tempfile'
require 'fileutils'

def safe_write(path, data)
  tmp = Tempfile.new
  tmp.write(data)
  tmp.close
  FileUtils.mv(tmp.path, path)
end

This will write data to a temporary file, then move it to the "/path/to/file" location atomically, without readers ever seeing the zero-length truncated version.

Upvotes: 4

Related Questions