From: Ersek, Laszlo on 12 May 2010 21:24 On Wed, 12 May 2010, yirgster wrote: > lacos writes: > >> I can't imagine that fsync() -- being permitted to ignore any changes >> made through a different file descriptor -- would be *required* to care >> about modifications performed through something that is not even a file >> description. > > Sounds correct. But, it's not relevant to the issue of mmap() of a file > description being implied by fsync of the same fd. Of course it's relevant. There is no "same fd". mmap() uses the file descriptor temporarily to get to the file description, and then to the regular file. Once the mapping is established, that is, the necessary kernel structures are set up to translate addresses to file offsets transparently and whatever else, there is no file descriptor or file description involved anymore, even if you didn't yet happen to close the file descriptor you originally passed to mmap(). The file descriptor in question is not required to have any memory of it ever being used to establish any mapping, and the mapping is free not to remember the fd it was established via. >> In closing, if you don't mind, I'll quote myself; it seems relevant to >> some extent. > > I rarely mind advertisements for myself. Even from others. I do it all > the time. > >> Would anybody please validate the following table? > > Validate your table? I am sufficiently trustworthy (forget > knowledgeable)? :) I do appreciate your input, but the outermost quote was Rainer's :) >> +-------------+----------------------------------------------------------------+ >> | change made | change visible via � � � � � � � � � � � � � � � � � � � � � � | >> | through � � +----------------------------+-------------+---------------------+ >> | � � � � � � | MAP_SHARED � � � � � � � � | MAP_PRIVATE | read() � � � � � � �| >> +-------------+----------------------------+-------------+---------------------+ >> | MAP_SHARED �| yes � � � � � � � � � � � �| unspecified | depends on MS_SYNC, | >> | � � � � � � | � � � � � � � � � � � � � �| � � � � � � | MS_ASYNC, or normal | >> | � � � � � � | � � � � � � � � � � � � � �| � � � � � � | system activity � � | >> +-------------+----------------------------+-------------+---------------------+ >> | MAP_PRIVATE | no � � � � � � � � � � � � | no � � � � �| no � � � � � � � � �| >> +-------------+----------------------------+-------------+---------------------+ >> | write() � � | depends on MS_INVALIDATE, �| unspecified | yes � � � � � � � � | >> | � � � � � � | or the system's read/write | � � � � � � | � � � � � � � � � � | >> | � � � � � � | consistency � � � � � � � �| � � � � � � | � � � � � � � � � � | >> +-------------+----------------------------+-------------+---------------------+ > > Well, I'm not sure I understand your table completely. But here goes: > > Under MAP_PRIVATE, 2nd row, I don't understand the qualifications. It > simply seems to me: unspecified. From the mmap() page: "It is > unspecified whether modifications to the underlying object done after > the MAP_PRIVATE mapping is established are visible through the > MAP_PRIVATE mapping." So what would MS_SYNC, MS_ASYNC, have to do with > it? That language is reflected actually in the MAP_PRIVATE *column*, and the write() *row*". The "modification[] to the underlying object" is done through write(), and whether the change is visible via a pre-existent MAP_PRIVATE mapping is unspecified. +-------------+-----------------------------------------+ | change made | change visible via � � � � � � � � � � | | through � � +-------------+-------------+-------------+ | � � � � � � | CVV_1 | CVV_2 | CVV_3 �| +-------------+-------------+-------------+-------------+ | CMT_1 �| sentence_11 | sentence_12 | sentence_13 | +-------------+-------------+-------------+-------------+ | CMT_2 | sentence_21�| sentence_22�| sentence_23�| +-------------+-------------+-------------+-------------+ | CMT_3 � | sentence_31 | sentence_32 | sentence_33 | +-------------+-------------+-------------+-------------+ "It is <sentence_ij> whether a change made through CMT_i is a change visible via (a pre-existent) CVV_j." Example: i=3, j=1: "In order to make a change, effected through a write() syscall, visible to a pre-existent MAP_SHARED mapping, the system's read/write consistency is sufficient, or an msync(..., MS_INVALIDATE) call issued after the write() is sufficient." Cheers, lacos
First
|
Prev
|
Pages: 1 2 3 4 Prev: Problem with getopt_long_only() (GNU/Linux) Next: NETWORK MARKETING |