race between kqueue vnode note for writes triggering reads on a pre-mmapped file segment

2016-04-19 Thread tautolog
>Synopsis: race between kqueue vnode note for writes triggering reads on a >pre-mmapped file segment >Category: kernel >Environment: System : OpenBSD 5.9 Details : OpenBSD 5.9 (GENERIC) #1761: Fri Feb 26 01:15:04 MST 2016 d

Re: race between kqueue vnode note for writes triggering reads on a pre-mmapped file segment

2016-04-15 Thread Ben Woolley
Wait, would reading back over the mapping create a copy of the page? Even if the contents are identical, it would still be the write of a copy-on-write, I am guessing. I can write into a separate buffer and copy it into the mapping only if there is a mismatch, or I can use a periodic fork. That's

Re: race between kqueue vnode note for writes triggering reads on a pre-mmapped file segment

2016-04-15 Thread Ted Unangst
Ben Woolley wrote: > Do the updates of the mmap happen in the order that writes are made? > If so, I could at least tell when coherence was reached. > > But it isn't a huge deal. The main purpose was to be able to share > memory between workers, and I can just do a read() into the shared > memory

Re: race between kqueue vnode note for writes triggering reads on a pre-mmapped file segment

2016-04-15 Thread Ted Unangst
Ben Woolley wrote: > On both UFS and tmpfs, if you watch for updates to the file with > kqueue, and pre-mmap a segment of the file, using the kqueue data to > notify of updates to the file crusor, and append the file in a > separate process, the written contents will populate AFTER the kqueue >

race between kqueue vnode note for writes triggering reads on a pre-mmapped file segment

2016-04-14 Thread Ben Woolley
>Synopsis: race between kqueue vnode note for writes triggering reads on a >pre-mmapped file segment >Category: kernel >Environment: System : OpenBSD 5.9 Details : OpenBSD 5.9 (GENERIC) #1761: Fri Feb 26 01:15:04 MST 2016 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/com