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