Re: [sprog-users] Re: DBI Gear

[Grant M. <gr...@mc...>]

On Sat, 2005-07-02 at 13:22 +1000, Matthew Keene wrote:
> --- Grant McLean <gr...@mc...> wrote:
> > And likewise, I'd appreciate comments from people
> > who are building gears and have questions about how
> > things are meant to work (or why) or comments about
> > how things could be better.
> 
> The obvious thing is more complete documentation.  

Ahh the perennial bugbear.  As it happens though I quite
enjoy writing documentation so stay tuned.

> A 'How To' guide for gear developers would be excellent

Yes, I'll put something up on the web site.  A few pictures
could make some of the concepts clearer.

> - the gear internals guide that you've got is a good
> start, but I found it a little lacking in detail (and
> I've just read the scheduler internals document and
> found some more stuff in there which now starts to
> make a bit more sense).

I'll probably end up turning those documents into 
reference pages and have the more descriptive stuff with
background details on the web site.

> I was planning on making a
> start on a step by step guide when I finished writing
> the DBI gear, sort of like a 'Gear Development for
> Dummies'.  (We're not all rocket scientists, you know
> ;-)).  Obviously I could only put in the little I know
> so far and you have to fill in the rest....

I don't mind writing it and if you ask questions about 
things that aren't clear, then I'll have a better idea what
to write about.

> My other main complaint is not related to developing
> gears, but a tool usability issue.  When you right
> click on a gear on the palette the current behaviour
> is that the selected item is executed when you release
> the right mouse button.  

I'd never noticed that, since I am in the habit of holding 
down the mouse button and releasing it once I've highlighted
the required option.  I certainly haven't done anything to
make it disappear as soon as you release the button, so it
looks like I'll have to do something to allow it to stay.

On my systems though the delete option isn't selected unless
I move the mouse after the initial click.  If I just right
click and release, nothing gets selected.  Admittedly though
the mouse only needs to move one or two pixels to make a 
selection.


> One thing that I'm still a little confused by when
> writing the non-blocking version of this gear is how
> to give control back to the framework so that other
> events can be processed.  

'return' :-)

Seriously though, it's a cooperative multitasking 
environment so a long as your method doesn't return, no 
other method (or GUI update) will get a chance.

> The difficulty here is that
> I'm going to basically have a single event (executing
> the query) which will potentially consume a large
> amount of time before any data becomes available.  

Yes, this is the bit that needs to be in the other process.

> I'm
> planning to call can_read (or some equivalent) on the
> IPC file handle to determine whether there the worker
> has produced any data to be processed, 

Glib/Gtk support a callback interface which allows you to
register a handler routine which should be called when a
filehandle becomes readable/writable or when a timeout 
expires.

The ReadFile and CommandIn gears both only read from a 
filehandle from within IO event handlers.  They both use
the InputFromFH mixin class to manage that.

> should I just
> return from send_data without sending any messages and
> let the scheduler handle the looping, 

Yes, that's exactly what you should do.

> How often will the scheduler call the input gear's
> send_data method if it hasn't yet started producing
> any data ?

The scheduler only calls send_data when it has no messages
queued for delivery.  Immediately after calling send_data,
the scheduler goes to sleep, so it won't call send_data 
again unless something wakes it up.  The most likely thing
to wake it up is if your gear sends a message - which it 
would most likely do from inside an IO event handler.

It is possible that some other gear in the machine has an
IO or timeout event setup too.  If it fired and sent some
messages, the scheduler would wake, deliver the messages 
and then call send_data again on all gears that had a 
send_data method, before going back to sleep.  So it is 
possible that your gear could be asked to send data more 
than once.  It ought not to be hammered with requests 
though.

>   I'm a little conscious of consuming CPU
> needlessly cycling around waiting for data if it's
> going to take some time to arrive, and I had been
> planning on putting a second or two's sleep time in
> the loop just to make sure that it doesn't put a hard
> head lock on the CPU.

It shouldn't be necessary to use sleeps.  Indeed if your 
code is sleeping, no other code is running.  If your code runs
in response to a filehandle becoming readable then other code
can run until that happens.

Regards
Grant