[ruby-talk:6415] Re: lots of Threads

[e-mail] (Yukihiro Matsumoto) wrote:
> Hi,
> In message "[ruby-talk:6408] Re: lots of Threads"
>     on 00/11/17, "Brian F. Feldman" <[e-mail]> writes:
> 
> |> I really want two things for pthread:
> |> 
> |>   * scheme to get list of existing threads
> |>   * scheme to get stack region addresses for arbitrary thread
> |> 
> |> I can make pthread Ruby (especially GC) if I get these.
> 
> |You can do something like this.  It will let you always have whatever
> |info you need...
> 
> <snip Ruby/C mixture to explain the idea>
> 
> If all threads are created from Ruby, yes.  qscheme does this too.
> But my concern is the situation where Ruby embedded in the
> application, so that threads may be created out of Ruby world.

Well, in this case, wouldn't you have something like this?

struct rbVM {
	pthread_mutex_t Giant;	/* giant lock */
	pthread_mutex_t other, locks;
	struct rb_pthread_info *threads;
	struct rb_vm_info *vm;	/* GC stuff, etc. */
	more currently-global stuff;
};

int
thread_with_a_ruby_interpreter() {
	struct rbVM vm = rb_vm_new(code); /* init subsystems, create thread */
	return rb_vm_wait(vm);	/* like wait(2) and exit(2) */
}

I can't see a way that having a way to get the current list of threads will 
work nicely, especially as it's not going near the standard...  To find the
current stack, it could be done easily, and may be accepted as standard 
eventually.

But using this scheme, the rb_vm_new() would create the initial thread 
itself, so it knows the stack address (which it makes itself).  Then using
the other method I proposed, the implementation would be pretty 
straightforward.

The major problem I see with this is the rbVM.  To allow multiple instances, 
this would have to be done, unless there is a much better way :-/  It would 
then have to be stored somewhere (don't know where) that works with all 
Ruby's implementation or passed like VALUE self.  Is this kind of thing what 
you want, a system capable of having many VMs?  Or just threads in an 
application being able to create new threads in a current VM?

I'm very interested in this; my two biggest hopes for Ruby are "true" 
embeddability and optimization for more speed.  Perhaps I should look at 
what Tcl has done for both of these aspects.  (You are going to create
generational GC and bytecode compilation for Ruby, which would probably
help quite a bit with the speed aspect, ne? :)

> By the way, I was pretty impressed how easy to ready your Ruby/C
> mixture.  There should be the (complied) language like this
> somewhere.

I think that would be great!  I find some things generally simpler to do in 
C (arithmetic of some kinds, data structures like trees) mostly due to the
language being low-level.  Another strength of C that Ruby would be nice to
have would be mmap(2) (implemented as a subtype of String, I suppose).  
Other than that I find Ruby to be more natural.  To be able to use the two 
together, with the Ruby language (not the C API :), would be the single most
useful language I've ever seen!

Sorry for taking up so much bandwidth on the list;  Ruby's too fun!

--
 Brian Fundakowski Feldman           \  FreeBSD: The Power to Serve!  /
 [e-mail]                    `------------------------------'