Re: Threading performance

Hi,

In message "Re: Threading performance"
    on Tue, 25 Oct 2005 16:06:39 +0900, Wink Saville <[e-mail]> writes:

|1) What are the issues using  _THREAD_SAFE for cygwin?

_THREAD_SAFE means the platform has running pthread library.  I am not
sure if cygwin has one.

|2) If I were to create a more efficient implementation of 
|rb_thread_schedule, shooting for O(1), would that be interesting to anyone?

Yes, for me.  But I am not sure now that when we can merge the
implementation since we made 1.8 stable mode.

|3) To do a more efficient implementation I've already taken the first 
|step and split eval.c into 4 files eval.h, thread.c and thread.h, is 
|anyone interested in these files? Of course they would need to be 
|evaluated by some experts and probably changed, but I think refactoring 
|out the threading code makes sense. Note: Evan originally suggested this 
|to me when we talked at the Ruby Conference.

For the same reason (1.8 being stable mode), I am not excited about
separating eval.c into pieces.

|4) Is anyone interested in a light weight asynchronous messaging for 
|Ruby? By light weight I mean the performance decrease due to message 
|passing is low (use binary for marshaling) and by asynchronous I mean 
|that sending a message never blocks nor returns a value. Messages are 
|placed on a queue that the receiver will processes at a time of its 
|choosing.

AP4R?  <http://rubyforge.org/projects/ap4r/>

							matz.