[Pharo-project] Network training

Levente Uzonyi leves at elte.hu
Sun Feb 6 19:15:14 CET 2011


On Sat, 5 Feb 2011, Luc Fabresse wrote:

snip

> Hi Levente,
>
> Why I am doing Ocean  with Noury is:
>
> 1) Network never worked fine for me (NetNameResolver ,...). The API (Image
> side) is not OO (All concerns in Socket: IPV4, IPV6, TCD, UDP, ...).
> We first try to write unit tests and then we planned to redesign the API.
> But it implies to understand well the primitives and it is not EASY at all.
> Some are said old in comments (IPV4 primitives?), some are new  (IPV6?),...
> So it is a too HARD to understand this code without doc or  explanations
> (and you are right I am also a poor newbie).

There was an "old" implementation of sockets, where every socket had a 
single semaphore. The "new" implementation added separate read and write 
semaphores. I guess this change was around 2005, so you can assume that 
every VM has the "new" implementation.

There was another change for IPv6 support.AFAIK CogVMs don't have these 
primitives, but SqueakVMs do.

>
> 2)  I do not want to hear this sentence anymore: "Oh yes, you use a VM with
> an old version of the socket plugin. You should recompile the VM."
> NO! I CAN'T DO THAT BECAUSE (until recently) RECOMPILING THE VM REQUIRE DEEP
> KNOWLEDGE AND SOME BLACK MAGIC. (Thanks to Igor, Esteban and all others to

Sorry but this is simply bullshit, the result of some people spreading 
FUD. Recompiling the VM is easy. I could compile VMs when I was a Squeak 
newbie. The same applies for writing plugins.

> prepare a simple process for newbies like me such as checkout and compile).
>
>
> 3) Ocean idea: pull up the network stuff on the image side. use an FFI to
> call OS libs. With this approach I am able to: load new versions of the
> network without changing the VM, in the future directly call the new OS API
> (Grand Central on OSX for asynchronous sockets, --yes network libs
> evolve--...), write more high level code and it is  a little bit easier to
> debug it.

The idea is nice, but I guess the performance will be a lot worse than 
using a custom plugin.

>
> Ocean is our vision, perhaps it is wrong but I can not do better.
> It is not as complete as the plugin yet.
> We also plan to use either Alien+OS lib or the plugin as a backend for
> Ocean so the plugin will still be there at the end for those who want it.
> And for this last part, we will certainly need some explanations on the
> primitives in SocketPlugin code. So if you know it well, feel free to
> educate me.

I don't know it well, but I usually deeply explore the code if I want to 
know how it works (or how it should work). Googling mailing lists and the 
squeak wiki used to be helpful too.


Levente

>
> #Luc

snip




More information about the Pharo-project mailing list