nanogui: gdk port and nano-X
Subject:
Re: gdk port and nano-X
From:
####@####.####
Date:
31 Mar 2000 14:18:16 -0000
Message-Id: <20000331023914.C12142@www.easysolutions.net>
On Fri, Mar 31, 2000 at 08:47:05AM +0000, Morten Rolland wrote:
> Paolo Molaro wrote:
> >
> > > : 7) problems separating event-handling from the internals
> > >
> > > We need more input on this.
> >
> > Not everyone uses select() to check for input available on the
> > socket and it's not safe the way events are stored now (you need
> > a list, not a single storedevent to make it right).
>
Allright... I'm going to toss my 2 cents into the arena for what it's
worth, or not worth as the case may be :).
From a programmatic perspective adding lists of events instead is a
big pain. You need to traverse those lists, know when it's safe to
pull stuff off, and manage memory appropriately. Here is a <sarcasm>
fabulous place </sarcasm> for a memory leak to appear. When/if we add
the ability of the app to run in a seperate process from nano-X this
is just going to make things more complex. Not only that, but now
your talking about storing this stuff in memory, and how is that going
to fair well for low memory devices?
On the other end of the spectrum making our events more speedy appeals
to me in the extreme... for instance, right now we can only handle one
keypress at a time. Rather lame if you ask me. The keyboard data
should be read into a buffer and an EAGAIN will pop up when it's had
it's fill. Then process those in a bulk manner... this could also be
accomplished for mouse movements, etc. I'm not putting that into the
current keyboard low level driver but I would really like to... like
pass it a function pointer to pass the individual events to while
reading more than one off of the buffer at once. Much more efficient.
Now about this select() business... what did you have in mind? RT
signal queues?... this blows cross platformability, though it would be
interesting. poll?, just attempting reads? Of these select() would
probably be the least CPU intensive, with the possible exception of RT
sig queues. <Though I think the problem is too small to merit the
additional mess that comes with sig queues... only three or four
maximum inputs> Just attempting non-blocking reads would be
maddeningly grotesque at killing our CPU horsepower. I'm probably
missing something... is there another method that you can think of?
(Keep in mind we only have one process to deal with..., and opening up
multiple processes/threads doing blocking reads on the various inputs
seems to be a waste of memory)
Slightly confused, and feeling as though he didn't eat his wheaties,
Shane.
