mulix
Fri, 06 Jul 2001 05:59:18 -0700
On Fri, 6 Jul 2001, guy keren wrote:
> On Wed, 4 Jul 2001, mulix wrote:
>
> > i decided that as long as we use files, we might as well make full use
> > of them. therefore, i store in the file the 'biditext bidi' property in
> > plain text, as the tokens 'neutral', 'rtl' and 'ltr'.
>
> 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 code will 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...
> 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 :)
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.
consider this scenario:
a biditext enabled application starts up and tries to attach to a shm
segment. if the shm segment is non existent, biditext is disabled. if
the shm is existent, we can read from it the 'base biditext' proeprty
and whether biditext is enabled or disabled.
an r2l application will create the shm segment (or not) on startup, and
write to it the relevant values.
obvious advantage:
* very fast (shm is the fastest IPC mechanism)
obvious disadvantages:
* cannot be easily controlled from the command line (no rm,
touch equivalnet)
* harder to code.
* default is biditext disabled, unless we make sure to create
the shm segmnet with the right values before any biditext apps come up.
comments? i'm in favor of trying the shm approach, falling back to files
if it doesnt work out.
--
mulix
http://www.advogato.com/person/mulix
linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead