building for 1.9

[Steven Parkes]

Hey Lyle,

You mentioned in a couple of places that you'd been looking at making fxruby
work on 1.9.

Does that get rid of (or at least obviate the need for) the idle chore?
Since 1.9 uses native threads, can one expect real concurrency, at least to
the extent that the two event-loops/schedulers could do their blocking
selects (or the moral equivalent) independently ...

I thought I'd try first, rather than ask, but I haven't quite figure out how
to do a 1.9 build.

Trying to build 1.6.14, I get bollixed up on extconf.rb wanting ftools,
which isn't in 1.9 (as far as I can tell ...) I could go down the path of
figuring out tweaks to make that work, but ...

I also looked at building from trunk, but there is no extconf.rb ... I'm not
sure where that little piece of magic is supposed to come from (but I have
rather limited experience when it comes to doing much beyond "gem build" and
"gem install" with rubygems).

_______________________________________________
fxruby-users mailing list
fxruby-users@...
http://rubyforge.org/mailman/listinfo/fxruby-users

[Lyle Johnson-4]

On Tue, Apr 1, 2008 at 3:10 PM, Steven Parkes <smparkes@...> wrote:

>  You mentioned in a couple of places that you'd been looking at making fxruby
>  work on 1.9.
>
>  Does that get rid of (or at least obviate the need for) the idle chore?
>  Since 1.9 uses native threads, can one expect real concurrency, at least to
>  the extent that the two event-loops/schedulers could do their blocking
>  selects (or the moral equivalent) independently ...

Let me preface my remarks by noting that what I don't understand about
multi-threading issues is "a lot". I am always open to suggestions, or
better yet, patches. ;)

Because I haven't had a chance to take a hard look at how threads work
in Ruby 1.9, the way that FXRuby *currently* handles threads in Ruby
1.9 hasn't changed. 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. 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. It might simply involve
invoking the FXApp#run method in a Ruby thread.

It may be worth noting that chores are fundamentally different from
threads in that they are only "scheduled" when the event queue
empties. You're not guaranteed that chores will run on a regular
basis, whereas a thread scheduler's job is to ensure that each thread
gets its fair shake. An advantage of using chores is that, since they
run in the same thread as the event loop, you don't have to worry
about the usual concerns associated with multi-threaded applications.

>  I thought I'd try first, rather than ask, but I haven't quite figure out how
>  to do a 1.9 build.
>
>  Trying to build 1.6.14, I get bollixed up on extconf.rb wanting ftools,
>  which isn't in 1.9 (as far as I can tell ...) I could go down the path of
>  figuring out tweaks to make that work, but ...

OK. You may be able to just remove that require statement (for
'ftools') and get it to work, but either way I'll look into this
before the next release. I think the last time I tried to build it
against Ruby 1.9 was before the 1.9.0 release so I suspect some things
changed in the final release.

>  I also looked at building from trunk, but there is no extconf.rb ... I'm not
>  sure where that little piece of magic is supposed to come from (but I have
>  rather limited experience when it comes to doing much beyond "gem build" and
>  "gem install" with rubygems).

The trunk version is the development branch for FXRuby 1.8, and it's
definitely not building at the moment. The FXRuby 1.6 code lives on
the RB-1.6 branch, but even there, what you get when you check out the
code isn't identical to what's distributed in the source tarballs and
gems. 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.

[1] http://www.infoq.com/news/2007/05/ruby-threading-futures
_______________________________________________
fxruby-users mailing list
fxruby-users@...
http://rubyforge.org/mailman/listinfo/fxruby-users

[Steven Parkes]

        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
        empties.

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 ...

_______________________________________________
fxruby-users mailing list
fxruby-users@...
http://rubyforge.org/mailman/listinfo/fxruby-users

[Lyle Johnson-4]

This is just a quickie reply while I'm waiting for dinner to finish...

On Apr 1, 2008, at 5:51 PM, Steven Parkes wrote:

> 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...

Look into the FXGUISignal class from the FOX library; I think under  
the hood it's implemented using a pipe that the non-FOX thread writes  
to to wake up the FOX thread. (Maybe a different implementation on  
Windows.) That class currently isn't exposed by FXRuby (because we  
haven't needed it) but I could do so if it proves useful.

> 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.

Yes. ;)

>
> 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
> ...

OK.

>
> 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 ...

OK. Let me know if you run into problems.

Thanks,

Lyle

---
"FXRuby: Create Lean and Mean GUIs with Ruby"
Now available as a Beta book from the Pragmatic Bookshelf
http://www.pragprog.com/titles/fxruby



_______________________________________________
fxruby-users mailing list
fxruby-users@...
http://rubyforge.org/mailman/listinfo/fxruby-users