Umm, I happend to be put into the position where one have
to express the opinion.

> Re:
> >> ...at this point the Squeak primitives have been implemented and 
> >> debugged on quite a number of platforms including the Sharp iCruise...
> >
> >	Does the iCruise pose a special challenge?
> 
> Not that I know of. However, Yoshiki spent quite a bit of time
> doing the implementation and he's a graduate student with limited
> time for Squeak VM hacking. So I'd rather not ask him and the
> other VM implementors to implement an entirely new set of socket
> primitives.

  As a matter of fact, what took time about ICRUISE network
support most was poor document: it seems to me that the
document assumes that the programmer will never try to use
non-blocking socket. (even for usual network applications,
the document is insufficient.) Now I think I know the
network API well and I could implement a working version of
Correspondents framework support code for ICRUISE in a
couple of days, weeks, or something.

# The other thing made me reluctant to write the network
# support code was I had to pay my ISP provider for the
# connection fee while I was debugging the code:-)  I think
# the total fee is more than 3000 yen.  I've never imagined 
# I have to pay for debugging code.

  And I don't like the idea of "polling" in handleEvents() I
wrote.

  So I would be happy if I could write the network support
code without non-blocking socket or polling.

  However, if the answer is the OS-level thread, I can't
agree it.  The thread of Zaurus OS is so limited that, for
example, one cannot even kill the other thread.  So it is
impossible to implement "abortable" socket as Andreas wrote.

  Apart from Zaurus OS and network support, I think the last
thing Squeak should depend is OS native thread, whose API
and behavior vary from platform to platform.  If Squeak uses
OS native thread, there would be many settings for VM
implementors to decide such as the priority, the interval to
check the semaphore signal, etc.  It will be quite hard to
find "optimal" setting and the portability of the support
code would be gone.  For instance, some OS automatically
change the priority of thread based on the "decency".  One
might have to struggle with such OS.

  On some OS, the thread library is buggy: this is not the
Correspondents framework problem, but ...

  Further, on some OS, the cost of context switch of threads
is pretty expensive.  When I wrote a version of VM that used
the OS thread for event handling for Zaurus, the performance
of VM was miserable because of the frequent context switch.
The polling may be inefficient, but multi-threading may not
solve the problem.

  Now, we have the VMs with small assupmtion on the host OS.
Thinking the cost of increasing the dependency to the host
OS, the current implementation + small enhancement (such as
properly implemented listen and accept) seems the answer.

                                            OHSHIMA, Yoshiki
                                       A nameless student of
                Dept. of Mathematical and Computing Sciences
                               Tokyo Institute of Technology 

P.S.
  When I said "please call me Yoshiki" at OOPSLA, what I
meant was "if you want to call me in first name, the way
Americans usually do, please call me Yoshiki".  You may call
me "Yoshiki", "Ohshima", "Ohshima-san" or whatever.