#I'll keep that in mind next time I announce software.
fwiw, your software (myriad/event) is on my radar watch.
It is truly remarkable on how you create complex/geeky things like io/networking stuff in a very simple and consistent way.
thanks for myriad/event (keep on working on it -and also on scgi).
kind regards -botp
I second this sentiment, I saw the announcement of myriad/ruby_event
yesterday and decided to recreate my chatserver which uses a select
loop with the orc_server.rb example as the basis. Took a couple of
hours and works a lot better than my home grown effort:)
one question regarding database access. twisted has some kind of
threaded pool of database connections that doesn't let it block or at
least minimises blocking, what's the best way to accomplish this in
myriad/ruby_Event.
thanks
R
A general question -- what do you mean when you say that it doesn't let it
block or at least minimises blocking? Won't it block while waiting for a
database connection if all of the connections are currently busy?
Thanks,
Kirk Haines
On Thursday 08 September 2005 7:11 am, rmt512@gmail.com wrote:
one question regarding database access. twisted has some kind of
threaded pool of database connections that doesn't let it block or at
least minimises blocking, what's the best way to accomplish this in
myriad/ruby_Event.
...
I second this sentiment, I saw the announcement of myriad/ruby_event
yesterday and decided to recreate my chatserver which uses a select
loop with the orc_server.rb example as the basis. Took a couple of
hours and works a lot better than my home grown effort:)
That's really cool. The OneRoomChat was mostly an example of how vrec
works as a means of passing messages instead of line-endings. If I were
to do orc as a *real* chat thing, I'd probably ditch the one vrec per
message param and go with a single vrec per message containing something
like YAML commands or simple shellwords commands. Oh, and also make it do
more than one room. 
one question regarding database access. twisted has some kind of
threaded pool of database connections that doesn't let it block or at
least minimises blocking, what's the best way to accomplish this in
myriad/ruby_Event.
Well, there's three ways to answer this depending on what you need:
1. You need to just access a DB without blocking all the other libevent
stuff. This is going to be really hard without some form of native
threading or a pure Ruby DB interface. Most of the DB api's are blocking,
so you've got to wrap the call with some kind of threading. I'm also
pretty sure that, even if the DB supports async queries, the Ruby DBI
doesn't (CMIIW). If the Ruby DB support is native Ruby, then the simplest
solution is to create your own pseudo-async query mechanism running in a
Ruby thread. This second option is complicated with stuff like having to
create a timer to periodically make Ruby run, etc. I may look at
something to support registering a Ruby thread with libevent for
operations like this. Take a look at the Myriad.timeout function. You
can do stuff like this:
timeout = Myriad.timeout(2,0) do
puts "2 SECONDS!"
timeout.enable
end
And myriad will loop the block every 2 seconds without blocking libevent.
2. You want a database framework written in Myriad. Remember how you
said Twisted was complicated? I wonder why Twisted would be so
complicated. Hmmmm. Maybe it's because they have too much in it?
Seriously though, if someone was really interested in doing this then
that'd be cool, but I'd make it a separate project. I like things being
nice, small, discrete and orthogonal.
3. Your question really has nothing really to do with DBs and more to do
with running non-Myriad stuff without blocking Myriad. You've got
basically the same problem as with the DB: either you need a native
thread, a ruby thread, or you need to invert who's in control (i.e. say
the GTK event loop rather than libevent loop). See above for the native
thread and ruby thread possibilities. The Myriad.timeout will really help
with this. To invert the loop, you need to dip into the base Event module
with:
Event.init(10)
# do you myriad configs like normal here
Then somewhere in the other event loop (like GTK's) during it's "idle"
phase you do:
Event.loop(Event::NONBLOCK)
To get Myriad to go once without blocking (actually libevent, but same
difference).
Anyway, that's the long winded answer. The short answer is I'll look at
Ruby Threads and Myriad integration which might solve some of the
problems.
Zed A. Shaw
to be honest I don't know exactly what it was doing, getting my head
round twisted was difficult enough without looking under the hood. from
that perspective myriad is much easier, as is it's implementation.
http://twistedmatrix.com/products/enterprise
from the page ...
"
Twisted provides an interface to any Python DB-API 2.0 compliant
database through an asynchronous interface which allows database
connections to be used, and multiplexed by multiple threads, while
still remaining thread-safe for use with Twisted's event-based main
loop. Twisted Enterprise provides these services by leveraging Twisted
Internet's utilities for managing thread pools and asynchronous
programming."
The short answer is I'll look at
Ruby Threads and Myriad integration which might solve some of the
problems.
Right on
Your question really has nothing really to do with DBs and more to do
with running non-Myriad stuff without blocking Myriad.
I noticed this problem in another way. My old chatserver started DRb
and handed it the server class so I could quickly get number of
chatters, chatter list etc, for an admin program. DRb didn't interfere
with the select loop and runs in it's own thread fine, at least that's
my understanding.
When i start my myriad version the entire program just stalls when i do
this
DRb.start_service("druby://localhost:#{ARGV[1].to_i+10}",@@rooms)
Myriad.run do
Myriad.trap('INT') { Myriad.shutdown }
listener = Myriad::Listener.new(ARGV[0], ARGV[1],
OneRoomChatServer)
end
now I'm thinking, maybe the Event.loop(Event::NONBLOCK) would be good
inside the Drb service somewhere? this isn't actually that important to
me right now, just pointing it out.
R