OSNews

nfeske,

"Your example does indeed subvert the locking scheme. But as Genode does not provide fork(), it wouldn't work anyway. ;-)"

Shows what I know


"The file-system interface is designed such that the seek offset is passed from the client to the file system with each individual file-system operation."

Makes sense. How do you handle files with the append flag?

int f=open("xyz", O_WRONLY | O_APPEND | O_CREAT, S_IRUSR | S_IWUSR);
sleep(1);
write(f, "1", 1);
sleep(1);
write(f, "2", 1);
close(f);

Running two instances of this program simultaneously on linux produces "1122". However if libc uses a process-local file offset, then it would probably output "12". I imagine you just ignore the offset that gets passed for files opened in append mode?


"To prevent falling into the premature-optimization trap, I'd first try to obtain the performance profile of a tangible workload."

A simple test here on an arbitrary linux system:

char buffer[1000];
int f=open("xyz", O_RDWR | O_APPEND | O_CREAT, S_IRUSR | S_IWUSR);
for(i=0; i<1000000; i++) {
/* TEST 1
off_t old = lseek(f, 10, SEEK_CUR);
lseek(f, 10, SEEK_SET);
read(f, &buffer, sizeof(buffer));
lseek(f, old, SEEK_SET);
*/
/* TEST 2
pread(f, &buffer, sizeof(buffer), 10);
*/
}

I recorded the fastest time of 3 runs...
buffer size=1
TEST 1 - seek + read = 1.072s
TEST 2 - pread = 0.663s

buffer size=1000
TEST 1 - seek + read = 1.254s
TEST 2 - pread = 0.882s

buffer size=10000
TEST 1 - seek + read = 3.636s
TEST 2 - pread = 3.183s


I'm a little surprised that even with a 10K buffer size, there's still a very noticeable half-second difference with the lseek syscall approach on linux. I suspect Genode-Noux would exhibit similar trends. But does it matter? That depends on who we ask. Sometimes design factors are worth some additional overhead. There are always trade offs.