native threads

C. David Shaffer cdshaffer at acm.org
Mon Apr 18 14:56:14 UTC 2005


Ramiro Diaz Trepat wrote:

>I believe my point is not minor or foolish.
>I think I might have overreacted to a subtle thing like defending the
>right cause for the wrong reasons, when I heard that the best mail
>client, web server, etc. were Squeak's, and that there was no problem
>whatsoever with green threads.

I don't support the mail client claim.  Celeste has never worked well
for me (I use _IMAP_ and only _IMAP_) plus I deal with lots of
multimedia e-mail.  I'll stick to mozilla mail.

>A few months ago, Harvard University's director said that women were
>not performing as well as men on natural sciences. He said something
>that is not an allowed "statement" in the world of political
>correctness; he was heavily attacked, but not honestly questioning his
>statement, but rather with a message like "this is something no one
>says by now... you should know, you animal".

That and the lack of hard scientific evidence to support any such claim.

> That's sad...
>I think it is not a proper attitude to consider such an important
>issue as the Squeak threading model not ever using native threads as
>closed.

I agree.

>In spite your employer does not use them, I'm sure native threads will
>be needed in some context.

Yes!

>The most judicious answer (I think it was from Göran), suggested that
>probably the best model would be to have a pool of native threads and
>a larger pool of green threads running on them.
>And if you remember, I reacted because I did not like the idea of
>sprinkling my code with Processor yield statements. Then, Ned and
>others clarified that I should never ever write that statement. But I
>think I got the confusion because the only way to get that famous
>SharedQueue filled unsequentially was including the yields in the
>blocks or else... rewriting the scheduler ! :)

This misinformation is getting out of control:

"section 1"
sq := SharedQueue new.
[10000 timesRepeat: [sq nextPut: 1]] fork.
[10000 timesRepeat: [sq nextPut: 2]] fork.

"section 2"
sq size

"section 3"
frontCount := 0.
[sq next = 2] whileFalse: [frontCount := frontCount + 1].
frontCount

Execute the first section of code above.  Wait until it is done (use the
ProcessBrowser to confirm that the two processes are complete).  Print
the second section to confirm that the size is 20000.  Print the third
to see that the first process did not complete before it was preempted. 
If you don't see that (all 10000 are in the front of the queue), up the
numbers by an order of magnitude and try again...your machine may be
faster than my old 800Mhz machine.  Now, what are you talking about? 
What is the problem you're having with Squeak's scheduler (besides
confusion in this thread)?

David
-- 
C. David Shaffer
http://www.cs.westminster.edu/~shaffer
http://www.shaffer-consulting.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20050418/a3e882e4/attachment.htm


More information about the Squeak-dev mailing list