14 Mar, 2010, Deimos wrote in the 1st comment:
Votes: 0
So, in deciding whether or not I wanted to upgrade to Ruby 1.9 or not, I noticed a pretty significant difference - supposedly it has support for OS-level threads now (amusingly called "Fibers"). This kind of excited me, and prompted me to wonder if anyone has attempted a multithreaded Ruby MUD design? Having AI run on a separate CPU/core from the rest of the game would be all kinds of awesome, no?

Edit: Guess I should have known better than to rely on Stack Overflow :redface:
14 Mar, 2010, Tyche wrote in the 2nd comment:
Votes: 0
You mean this?
http://stackoverflow.com/questions/56087...

AFAIK, the Jorg chap has a good answer.
14 Mar, 2010, Deimos wrote in the 3rd comment:
Votes: 0
Yeah, but the guy he was replying to said that Fibers would be native threads, which I found out isn't true after all, and I'm not keen on trying something like JRuby yet. Still working on the reference implementation!
14 Mar, 2010, quixadhal wrote in the 4th comment:
Votes: 0
That's a good thing!

Pre-emptive multi-tasking is not as good as co-operative multi-tasking. You (or more properly, your application) have much better knowledge of when to yield control to other threads than some generic scheduler in the kernel, which has no idea of anything beyond how many milliseconds have elapsed, how many CPU cycles you've used, and what (if any) pending signals there are.

It does, however, require you to think a bit, rather than just pretending everything is running at once under the delusion the OS provides for you. :)
14 Mar, 2010, David Haley wrote in the 5th comment:
Votes: 0
quixadhal said:
It does, however, require you to think a bit, rather than just pretending everything is running at once under the delusion the OS provides for you. :)

Well, unless you actually have several processors (or a multi-core processor), in which case things change quite a bit. I don't think it's right to say that cooperative multithreading is generally better than preemptive multitasking: it depends a great deal on what you're doing. Sometimes (e.g. when tasks are parallelizable, and you are pressed for performance) true multi-threading is in fact vastly superior.

That said, I would argue that cooperative multithreading requires you to think, yes, but it's easier than preemptive multithreading.
14 Mar, 2010, Runter wrote in the 6th comment:
Votes: 0
I'd make the jump to 1.9 anyways. It really only benefits you. It is the new reference interpreter. 1.8's interpreter will not be used for 1.10 and beyond into 2.0.

Fibers in 1.9 are semi-co routines like coroutines in lua and generators in python.
14 Mar, 2010, Tyche wrote in the 7th comment:
Votes: 0
Runter said:
I'd make the jump to 1.9 anyways. It really only benefits you. It is the new reference interpreter. 1.8's interpreter will not be used for 1.10 and beyond into 2.0.

Fibers in 1.9 are semi-co routines like coroutines in lua and generators in python.


If he wants to play with Fibers sure. Here's a decent article with examples comparing them to threads and continuations.
Ruby 1.9 and I just don't get along. Now I expected to have problems with my old code. What I didn't expect was encountering segmentation faults and byte code dumps. So I *plonked* it.
14 Mar, 2010, Runter wrote in the 8th comment:
Votes: 0
Tyche said:
Runter said:
I'd make the jump to 1.9 anyways. It really only benefits you. It is the new reference interpreter. 1.8's interpreter will not be used for 1.10 and beyond into 2.0.

Fibers in 1.9 are semi-co routines like coroutines in lua and generators in python.


If he wants to play with Fibers sure. Here's a decent article with examples comparing them to threads and continuations.
Ruby 1.9 and I just don't get along. Now I expected to have problems with my old code. What I didn't expect was encountering segmentation faults and byte code dumps. So I *plonked* it.


Particularly code that extended the C interpreter has issues. I converted my projects over and haven't looked back for about a year now. There were many popular gems that took a while to be compatible. Most are now it seems. I don't have any segmentation faults or byte code dumps. In any event, it's just prolonging the problem. Eventually 1.9 will (and already is in some cases) going to be the standard distributed package of choice. I think waiting until the difference in 1.8 and 1.9 is even greater would be a mistake for someone developing a project they intend to convert over in the future. Especially if they continue to write with practices that are not compatible with 1.9.
14 Mar, 2010, Tyche wrote in the 9th comment:
Votes: 0
Runter said:
I don't have any segmentation faults or byte code dumps. In any event, it's just prolonging the problem. Eventually 1.9 will (and already is in some cases) going to be the standard distributed package of choice. I think waiting until the difference in 1.8 and 1.9 is even greater would be a mistake for someone developing a project they intend to convert over in the future. Especially if they continue to write with practices that are not compatible with 1.9.


I still do. Now I've been subscribed to the ruby lists for over five years now and have been hearing the same wonderful happy messages about Ruby2 for that long as well. So it's not like I'm impatient. There are three distinct forks of ruby controlled and maintained by separate groups, the 1.8.6, 1.8.7, and the 1.9.x branches. The resemblance to the Perl 5.x/6.x fiasco is uncanny. All the different versions will be around for quite awhile. Perusing the commits and feature requests sets is illuminating. Some have suggested the 1.9 team has spent somewhere between 50%-80% of their time in the last 5 years wasting their time on endless syntactic sugar subtleties that only a handful of users care about.
14 Mar, 2010, Runter wrote in the 10th comment:
Votes: 0
Regardless, books being written, courses being taught, etc etc are using 1.9 as the reference language. This has all changed very quickly in the last year.

Is your position that you just aren't going to switch over to 1.9 until certain conditions are true? Or that you just are never going to switch over and continue using an alternative implementation?
14 Mar, 2010, Tyche wrote in the 11th comment:
Votes: 0
Runter said:
Is your position that you just aren't going to switch over to 1.9 until certain conditions are true? Or that you just are never going to switch over and continue using an alternative implementation?


I'll probably wait 'til the version number actually switches to 2.0. ;-)

In any event, the Fibers thing is tempting and solves a lot of muddish problems.

I can't find the exact thread, but this one on TMC includes some of my rants on preemptive threading. It was an earlier thread with Erwin I think where I was advocating (pining) for a decent mechanism like Windows Fibers, PThreads, even Windows 3.0 time-slicing, or manual time-slicing to do anything to avoid preemptive threading to do real cool things in muds.
15 Mar, 2010, Runter wrote in the 12th comment:
Votes: 0
Isn't there libraries for 1.8x to accomplish the same thing as Fibers? Continuations or some such?
0.0/12