fork of 9front i guess
cb35d1a132
to allow bytewise access to /proc/#/fd, the contents of the file where recreated on each call. if fd's had been closed or reassigned between the reads, the offset would be inconsistent and a read could start off in the middle of a line. this happens when you cat /proc/#/fd file of a busy process that mutates its filedescriptor table. to fix this, we now return one line record at a time. if the line fits in the read size, then this means the next read will always start at the beginning of the next line record. we remember the consumed byte count in Chan.mrock and the current record in Chan.nrock. (these fields are free to usefor non-directory files) if a read comes in and the offset is the same as c->mrock, we do not need to regenerate the file and just render the next c->nrock's record. for reads smaller than the line count, we have to regenerate the content up to the offset and the race is still possible, but this should not be the common case. the same algorithm is now used for /proc/#/ns file, allowing a simpler reimplementation and getting rid of Mntwalk state strcture. |
||
|---|---|---|
| 386 | ||
| 68000 | ||
| 68020 | ||
| acme | ||
| adm/timezone | ||
| alpha | ||
| amd64 | ||
| arm | ||
| lib | ||
| mips | ||
| power | ||
| power64 | ||
| rc | ||
| sparc | ||
| sparc64 | ||
| sys | ||
| .hgignore | ||