Re: gEDA-dev: DBUS binding to PCB actions

[Peter Clifton <pcjc2-at-NOSPAMcam_dot_ac_dot_uk>]

[snip]

> """
>   hidval watch_file (int fd, void *user_data, void (*callback)(int, void
> *));
>   void unwatch_file (hidval which);
> """
>
> > > Since the watch types, G_IO_IN, G_IO_OUT, etc.. might not be guaranteed
> > > to line up with the enum constants in other mainloops (but probably
> > > will, as presumably they are just passed to select), do we need to write
> > > our own enum list, and map it onto the correct values in each hid?
> > 
> > I'd say ignore the condition.  Just do read/write/close, that's all
> > that really happens on normal sockets.  The hid can call a polling
> > select() to figure out what states are ready on the file.

I've had to implement a local list of conditions to be passed onto the
mainloop. It seems that if we always test for write, we return lots, and
burn loads of CPU time checking if we can read or not. I will post a
patch for review when I've had a chance to tidy it up, and implement in
lesstif as well as GTK.

What is slightly harder, is the need to break into each iteration of the
mainloop for dispatching queued messages. I have implemented a HID
function which registers "prepare", "check" and "dispatch" callbacks for
integration with the HID's mainloop.

The functions follow glib styling, with "prepare" called before a
mainloop iteration polls its descriptors, (returning TRUE if we can
"dispatch" at this point, "check" - perhaps un-necessary for us, is
called after the descriptors are polled, and returns TRUE if there is
now something we can dispatch. "dispatch" is called both when "prepare"
or "check" return true.

In the GTK hid, I subclass a GSource, and add that into the mainloop.
The subclassed GSource functions are basically a wrapper, which call
PCB's, callbacks.

I think I know how to do it in Lesstif, which internally uses a very
simple mainloop:

man XtAppNextEvent(3)
"""
There is nothing special about XtAppMainLoop; it is simply an loop that
calls XtAppNextEvent and then XtDispatchEvent, until XtAppGetExitFlag()
returns true.

Applications can provide their own version of this loop, which tests
some global termination flag or tests that the number of top-level
widgets is larger than zero before circling back to the call to
XtAppNextEvent.
"""

I will look at doing a XtAppMainLoop variant which calls any registered
callbacks, dispatching as necessary.

The other way we "could" do this is with a timeout to run the dispatch
process, however whilst more complicated, they way I'm attempting to do
it at the moment, is more "proper".

I've not had a lot of time for coding this weekend, as I spent the day
changing a clutch, and tomorrow is earmarked for towing my new car
project to where I'm going to replace its engine!

Regards

Peter Clifton




_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev