[fxruby-users] building for 1.9

Steven Parkes smparkes at smparkes.net
Tue Apr 1 18:51:24 EDT 2008

	or better yet, patches

Looking at it ...

	The FOX event loop is in charge, running in the
	primary thread, and it sets up a chore that periodically yields time
	to Ruby's thread scheduler.

Okay. Good. Same as 1.8, so I know where we're starting from.

	If there's a way I can modify this so that
	the event loop thread cooperates with the Ruby thread(s) in a more
	straightforward way, I'm open to that.

I've been wondering about lowering the thread priority of the fox event-loop
thread and calling Thread#pass instead of wait. On the good side, if the
ruby scheduler has nothing to do, it will return to fox immediately rather
than sleep. On the bad side, the event loop will never get entered again
until the ruby scheduler has nothing else to do (where as right now it's a
peer to other ruby threads as long as it's not sleeping). That's kinda like
what happens in most event-loop apps anyway, if the call back never returns
(the gui freezes) ... but, then, they usually don't have embedded scheduler.

The fox docs have the typical comments about event-driven apps usually being
pretty light in the callbacks. If the code ruby is going to schedule is also
light, multithreaded or not, it should be okay to lower the priority. But
it's still cooperative multithreading. If any of those tasks do, for
example, any c-extension I/O, well ...

1.9 could make things slightly better, letting both ruby and fox block.
Maybe. I'm not sure, but investigating. It still leaves open how one
notifies/wakens the other side. It might not be too hard to have fox wake
ruby threads; I think it has an API for that (but I'm not 100% sure either).
Going the other way, I didn't say any obvious indications of fox having an
API to be wakened. Seems like it'd be possible to have a socket that could
be used just for signaling that would fit in the select() scheme (though I
don't know how well that would work on Windows).

	It may be worth noting that chores are fundamentally different from
	threads in that they are only "scheduled" when the event queue

That, plus there are lots of other things going on in the loop that aren't
"events". In particular, the gui-updates are delayed and then run when the
event queue is empty. The fox docs say

	"The GUI update and the Chore processing are interleaved, so that
each time through the event loop, at least one GUI update callback and one
Chore are always being executed."

and I haven't yet gotten comfortable that I know significance of that if the
chore is a ruby schedule.

I'm still trying to work through how the two schedule loops could cooperate
for "best results", where a big step is figuring what "best results" means.
For my own work, I'm wondering if I need to do most of the ruby work in
another process, with just a little ruby to get things between processes.
Even in that case, the I/O necessary to do the IPC would still need to be
integrated with fox.

	You may be able to just remove that require statement (for
	'ftools') and get it to work

Yeah, I went that far, but ftools has File#move which is actually used. I
may dig a little deeper now that I know 1.9 support is at least on the table

	Many of the distribution files (including extconf.rb) are
	automatically generated from templates by a Rake task and aren't
	actually checked in to the Subversion repository.

I figured it was something like this. I'll get the 1.6 branch and dive a bit
more into the rake stuff ...

More information about the fxruby-users mailing list