guy keren
Sat, 07 Jul 2001 17:18:24 -0700
On Fri, 6 Jul 2001, mulix wrote: > > oh! but thus you have defeated tzafrir's original purpose of using the > > file size - so the data can be taken with a single fstat() call, rather by > > using fstat(), open(), read() and close(). remmeber this codewill be > > invoked on each XDrawString* function call inside biditext.so ... > > is this absolutely necessary? if we add polling, in whatever sort, the > value can be cached until we get a notification that it has changed. if > we assume no polling, however... we don't rely on notifications for now. you should either use the file's size, or the file's mode (fstat() returns the file's permissions as well. there are various commands that use file permissions for various checks, for example comstat() and talkd check the permissions on the user's tty file to see if the user enabled/disabled getting new mail messages, or talk requests, respetively. 'biff y' and 'biff n' is merely a chmod on /dev/tty . the same goes for 'mesg y' or 'mesg n'. > > i suggest you switch back to reading file sizes. > > i dont like this way. it's a hack. let's see if we can find a better > hack :) biditext as a whole is a hack! it should be as little intrusive on applications as possible. > at first i thought of using mmap, but if we use mmap, as guy has > mentioned, we cannot know that when a file has been erased. so i took > things to the next logical conclusion, shared memory. what? shared memry now? you have any idea how problematic usage of shared memory is? also, you cannot delete a shared memory page if any process has it attached, so you cannot rely on its existance - only on its contents. you'll also have problems if you want many copies of biditext in memory, each usign a different shared memory segment - OSes limit the number of shared memory segments that can exist (OS-wise) at any given time. its hard to clean up shared memeory segments, since you have to explicitly erase them. > comments? i'm in favor of trying the shm approach, falling back to files > if it doesnt work out. if you wish to make a private version of the library with shared memoery - do so. but first - release a version that does the simple thing we asked for - using files, and using tzafrir's hack (file size) to check for bidi mode. then we could start working on ther others parts (putting the lib into biditext, and into r2l programs) and you can meanwhile play with it. please, lets be focused on having something working in 3.6 weeks from now.. -- guy "For world domination - press 1, or dial 0, and please hold, for the creator." -- nob o. dy