From: James Edward Gray II <james@...>
Date: 2005-09-08T22:36:17+09:00
Subject: Re: [SOLUTION] MUD Client (#45)

On Sep 7, 2005, at 10:33 PM, Morgan wrote:

> James Edward Gray II wrote:
>
>
>> A very basic quick solution I thew together.
>>
>
> And another question. You use a Queue in this.
> Do you actually need to do that?

When I start threading, I instantly activate my thread-safe  
paranoia.  I think that's a good habit to build really.  Threads are  
tricky, so I believe it's important to play it safe, whenever  
possible.  So to answer your question, yes, I need the Queue to feel  
comfortable.  Does Ruby need it?  I'm not sure.

> From my understanding (and a little testing), if you
> have one thread pushing items onto an array, and
> another thread using shift to pull them off (and ONLY
> one thread doing each), you'll still get all your data in
> proper order without having Thread.critical calls slowing
> down your application.

It wouldn't surprise me at all if you're right, but you're basically  
counting on Ruby internals here and I have a hard time seeing that as  
a good idea.  What if the scripting interface launches a Thread to  
scan the Queue for whatever reason?  Your assumptions have now been  
violated and who knows what's going to happen.  The user made that  
choice, so you were never consulted.

> Since I'm not sure how expensive
> all the *other* stuff my client will be doing will be, this
> is important to me. (That, and it's sort of an esthetic issue
> with me - if I can get away with not using Thread.critical,
> that's what I want to do.)

A client should have little trouble keeping up with a user and the  
average MUD on modern hardware, even when taking actions based on  
what it reads.  I expect it to be doing nothing a lot more often than  
not.  When I was in high school I played on a BBS (similar to MUDs)  
on a 66 Mhz machine and it kept up with me okay.  Network IO was the  
slow part then and still is now, so we should have plenty of  
processing time.

More importantly, when it starts getting slow, look for a way to  
speed it up.  Until then, why remove safety features for a problem  
that doesn't exist?  Remember, premature optimization is the root of  
all evil.

James Edward Gray II