File access questions

[Nathan Sims]

I have one Cocoa-based process that needs to publish a small amount of data (32 bytes) about 1/sec to n other C-based processes that are busy doing calculations. I was thinking of writing to a small file in /tmp, and then the other process could read it (if/when they choose to).

Q: Does a file opened for write-only "w" access preclude others from reading it? Will an open "r" call to a file that's being written simply hang until the writer closes it? Will a write-only open call on a file that's being read hang?

Perhaps there's a better approach to this...

[Kyle Sluder]

On Tue, Nov 15, 2011 at 6:02 PM, Nathan Sims

Post by Nathan Sims
Q: Does a file opened for write-only "w" access preclude others from reading it?

Nope. You want to look into file locks (flock), and realize they are
only advisory. There is no such thing as exclusive file access on
UNIX.

--Kyle Sluder

[SD]

If you are going to use files, then you want to use file locking.
Otherwise you'll end up with race conditions at the least.

See man flock

[Nathan Sims]

Post by SD
If you are going to use files, then you want to use file locking.
You want to look into file locks (flock)

The integrity of the data being written/read (from one update to the next) isn't critical (representing very small changes in temperature), so flock() looks like it should be sufficient if all processes cooperate.

Thanks!

[Kyle Sluder]

On Wed, Nov 16, 2011 at 9:36 AM, Nathan Sims

Post by Nathan Sims
The integrity of the data being written/read (from one update to the next)
isn't critical (representing very small changes in temperature), so flock()
looks like it should be sufficient if all processes cooperate.

In that case, why use a file at all? It sounds like you've got one
daemon that reports the temperature and N clients on the same machine
that poll for the temperature. Would another IPC mechanism be more
appropriate, like perhaps a Unix domain socket?

--Kyle Sluder

[Nathan Sims]

Post by Kyle Sluder
On Wed, Nov 16, 2011 at 9:36 AM, Nathan Sims

Post by Nathan Sims
The integrity of the data being written/read (from one update to the next)
isn't critical (representing very small changes in temperature), so flock()
looks like it should be sufficient if all processes cooperate.

In that case, why use a file at all? It sounds like you've got one
daemon that reports the temperature and N clients on the same machine
that poll for the temperature. Would another IPC mechanism be more
appropriate, like perhaps a Unix domain socket?

Wow, I didn't know about Unix domain sockets, but this seems to be a perfect fit. I can make the Cocoa process into a mini UDP server on a known sun_path, and the C processes can get the temp data from it by sending a request to the same sun_path and reading the response packet, all without connecting. That should be a little more elegant than using files.

Thanks!

[Kyle Sluder]

On Wed, Nov 16, 2011 at 12:03 PM, Nathan Sims

Post by Nathan Sims
Wow, I didn't know about Unix domain sockets, but this seems to be a perfect fit. I can make the Cocoa process into a mini UDP server on a known sun_path, and the C processes can get the temp data from it by sending a request to the same sun_path and reading the response packet, all without connecting. That should be a little more elegant than using files.

Technically it's not using UDP, since that's a protocol built on top
of IP (Internet Protocol) and thus only applicable to AF_INET sockets.
My guess is you want to use SOCK_SEQPACKET.

--Kyle Sluder

Post by Nathan Sims
Thanks!

You're welcome.

--Kyle Sluder

[Nathan Sims]

Post by Kyle Sluder
On Wed, Nov 16, 2011 at 12:03 PM, Nathan Sims

Post by Nathan Sims
Wow, I didn't know about Unix domain sockets, but this seems to be a perfect fit. I can make the Cocoa process into a mini UDP server on a known sun_path, and the C processes can get the temp data from it by sending a request to the same sun_path and reading the response packet, all without connecting. That should be a little more elegant than using files.

Technically it's not using UDP, since that's a protocol built on top
of IP (Internet Protocol) and thus only applicable to AF_INET sockets.
My guess is you want to use SOCK_SEQPACKET.

Hmm, isn't SOCK_SEQPACKET connection-oriented? If I use SOCK_DGRAM instead wouldn't that be a lot easier and lighter-weight, not having connections? I was going to do:

socket_fd = socket(AF_UNIX, SOCK_DGRAM, 0)

on both sides and then use recvfrom() and sendto() without connection on either side, which is about as simple as it gets, since all processes are on the same machine...

[Kyle Sluder]

On Wed, Nov 16, 2011 at 12:52 PM, Nathan Sims
Yes, but it guarantees order. If you're including your own timestamps
in the datagrams, then you can use SOCK_DGRAM and reorder them
yourself.

--Kyle Sluder

[Nathan Sims]

Post by Kyle Sluder
On Wed, Nov 16, 2011 at 12:52 PM, Nathan Sims
Yes, but it guarantees order. If you're including your own timestamps
in the datagrams, then you can use SOCK_DGRAM and reorder them
yourself.

If the server only "sends" an update packet to clients upon their request, packet ordering probably shouldn't come into play in this scenario, but nevertheless, that's an interesting tradeoff. I will consider it!

Thanks!

[Kyle Sluder]

On Wed, Nov 16, 2011 at 1:22 PM, Nathan Sims

Post by Nathan Sims
If the server only "sends" an update packet to clients upon their request, packet ordering probably shouldn't come into play in this scenario, but nevertheless, that's an interesting tradeoff. I will consider it!

Well, it doesn't matter, because it looks like SOCK_SEQPACKET isn't
supported for AF_UNIX. Since I do pretty much no sockets-related
programming, I was unaware of this.

If I understand what you're trying to accomplish, you need a way to
associate requests with responses. Otherwise the client could issue
two requests and get the responses in opposite order. Or, since
datagrams are unreliable, the client could issue two requests and only
get one response.

Again, not being a sockets programmer, I'm not sure if my next
suggestion is valid: consider using a SO_BROADCAST on your SOCK_DGRAM
socket, instead of providing the same data to each client in response
to a request.

--Kyle Sluder