On Wed, Jul 26, 2017 at 04:00:43PM -0400, Christopher Clements wrote:
> On Wed, Jul 26, 2017 at 10:56:13AM +0000, Enrico Weigelt, metux IT consult
> wrote:
> > On 26.07.2017 09:34, Didier Kryn wrote:
> > > and even unistd's write() and seek() are wrappers for kernel's pwrite().
> >
> > No. Just look at the code. write()+seek() as different semantics
> > than pwrite(), and they don't even need to be supported by some
> > particular fd.
>
> Wouldn't this work? (no error checking of course XD)
>
> off_t lseek(int fd, off_t offset, int whence);
> ssize_t write(int fd, const void *buf, size_t count);
> ssize_t pwrite(int fd, const void *buf, size_t count, off_t offset) {
> lseek(fd, offset, SEEK_SET);
> return write(fd, buf, count);
> }
User code:
Thread A:
pwrite(fd, "a", 1, 0);
Thread B:
pwrite(fd, "b", 1, 1);
Libc wrapper:
Thread A:
lseek(fd, 0, SEEK_SET);
write(fd, "a", 1);
Thread B:
lseek(fd, 1, SEEK_SET);
write(fd, "b", 1);
If the threads operate at one syscall per wakeup, instead of "ab" the file
will contain "\0ab". So use a mutex, you'd say? Try signal handlers then.
For the reverse, implementing write() and seek() by storing the seek
position in a variable, try an O_APPEND file opened by two different
processes, or something unseekable like a tty.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal
⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs (the five fishes + two breads affair)
⠈⠳⣄⠀⠀⠀⠀ • use glitches to walk on water
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
