Sam,
I may be totally off base here as much of the technical discussion
involving details of how gui toolkits normally handle this stuff is
over my head, but could you maybe handle your situation by using
queues to tie things together? For example, beanstalkd is a solid,
scalable queuing implementation with a good ruby front end:
http://xph.us/software/beanstalkd/
If you had one queue between each pair of processes (log parsing <->
sql lite, sql lite <-> shoes) your consumer could just pull of the new
messages from the queue at its own rate without having to block
waiting on the other process to answer a query and without having to
deal with the complexity of spawning additional threads.
Is this on the right track at all?
-- Greg
On May 27, 2008, at 1:27 AM, Sam Saffron wrote:
Hi Cecil,
Yerp, Im with you, I actually mentioned in my previous post Im going
to try launching
a child process and have it take care of the sqlite interaction.
That way I can keep my
gui code nice, light and predictable.
A trick I can use is to support some sort of async messaging between
my two processes,
then I can poll my sqlite process say once a second for new events,
and shoot events at it
whenver I want to.
Eg.
How many rows do you have?
What is the contents of rows 1-100?
Can you filter down so you only show the rows with contents "xyz"
I have done plenty gui coding in the .Net world and these are hoops
im not quite used to
jumping through but timers do not feel like a workable solution.
Cheers
Sam
On Tue, May 27, 2008 at 5:58 PM, Cecil Coupe <[EMAIL PROTECTED]>
wrote:
Sam,
I recommend a tiny rethink about your problem. I see two issues.
Populating the sqlite db is one and display it is another. Why use one
process to do both?
Ruby thread goodness (or lack of) is a bit of unwarranted FUD. If you
look hard enough, my name is on some of that old wxWindows code.I know
where it came from and threads and mulit-core weren't an issue back
then. Handling asynchronous events that have nothing to do with with
GUI
widgets or mouse clicks or keypress, those were wild dreams, Back
then,
there were no events to handle in a GUI framework other than GUI
related
events. So, we got timers IF the OS had them (back then it was iffy
they
would work cross platform at the millisecond tick rate) I gather "a
wing
and prayer" then is a promise now.
I'm not saying Shoes doesn't have some refresh issues or thread
funkiness that I don't understand but It's not pretending to be
WxWindows or TK or XVT or the Star Division library thing. Pretty cool
that it works cross platform as is. A modern day Ruby Hypercard (just
needs a few "on" handlers). If you look at the C and the #ifdef's
you'd
worry it'll bloat beyond comprehension for all the special cases folks
want it handle. It's still understandable (barelt)
Off the soapbox now. Sorry to bend your ears.
--Cecil
