mulix
Sat, 07 Jul 2001 17:34:28 -0700
On Sun, 8 Jul 2001, guy keren wrote: > > 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. right. so what? > 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. i need two bytes of shared memory, and one is enough if i care to use bits instead of bytes. i will check what's the limit on linux, but i doubt it will be relevant. > its hard to clean up shared memeory segments, since you have to explicitly > erase them. so? > > 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. i will. > 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. please, guy, the simple version you want is released and has been released since 05:22 on july 4th. it has the 'base biditext' support, and although it currently uses open/read/write, the interface is set and will remain the same no matter what method we choose. > 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. i will put out right now a new version with the file size hack. i will put out a shm version when i write it. > please, lets be focused on having something working in 3.6 weeks from > now.. please specify the next steps... -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead