Re: Threads killen

On Wed, May 14, 2003 at 10:10:20PM +0200, jonnypichler - bse wrote:
> was mich wundert: wie kannst du überhaupt die kill-methode aufrufen solange
> das child läuft - meine erfahrung ist, dass bei einem system()-call dem
> ruby-interpreter die kontrolle solange entzogen wird, bis der
> system()-prozess terminiert ist, auch wenn dieser in einem thread gestartet
> wird.
> macht ja auch sinn, weil rubythreads ja nur ruby-internal sind (siehe dein
> quellenverweis).
> oder kommt das nur daher, dass ich ruby unter win32 und nicht unter linux
> verwende?
ich denke, das is wegen dem win32. Welche win32-ruby version verwendest du?
die jenige, die cygwin verwendet, oder die andere (mscvc-compiliert glaub
ich).

> zitat aus "programming ruby" hierzu:
> ..And if some thread happens to make a call to the operating system that
> takes a long time to complete, all threads will hang until the interpreter
> gets control back.
Aber alle OS-calls die ruby selber macht, umgehen dieses problem.

das prinzip is folgendes:
statt einen blocking read macht man

fd auf nonblocking schalten
while(noch_nicht_genug_gelesen) {
	rb_thread_select([fd])
	read(fd)
}

rb_thread_select läßt den aktuellen thread schlafen, bis von einem der 3
übergebenen fds (filedesckriptoren) gelesen/geschrieben werden kann.

Alle standard-ruby io-commands machen das so. allerdings gibts einige
zusatzmodule (z.B mysql db-interface), die das nicht so machen. dort stehen
dann wirklich alle threads, bis die datenbank geantwortet hat.

> ich denke dieses "gets control back" geschieht erst durch das ende des
> child-prozesses...
ne, in diesem fall durch das rb_thread_select

grüße, Florian Pflug.

PS: Ich hab gerade in deiner sig gesehen, daß du ruby-cygwin verwendest. Is
komisch - mit cygwin sollte diese select-sache eigentlich funktionieren....
is vielleicht ein bug in cygwin...