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).
On Tue, Apr 1, 2008 at 3:10 PM, Steven Parkes <smparkes at smparkes.net> 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
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 ...
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