Unix socket code

Brian Rice water at tunes.org
Sat Jan 29 09:05:55 PST 2005


On Jan 28, 2005, at 11:51 AM, John Leuner wrote:

> Attached is my code for a 'unix socket' plugin.

Thanks!

> To run, you must untar the source files, modify your Makefile:
>
>  $(MAKE) -C src/plugins/smart-console/ncurses
>         $(MAKE) -C src/plugins/socket
>
> (add the extra make line)
>
> and then run: make plugins
>
> Then load: 'stest.slate'. (you must have set LD_LIBRARY_PATH before
> starting the vm (and you have to restart the vm every time you 
> recompile
> the .so))

Cool! I've simplified the structure a bit before adding it to CVS; I 
basically just used the structure from the console libraries to keep 
things simple.

Note: stest.slate is now tests/socket.slate (although it is no unit 
test).

> Notes:
>
> 1. I didn't know exactly what headers to include in unixsocket.c, so 
> the
> ones I have there are probably linux specific (and wrong)

It works on MacOS X (although fink is also installed on here, which 
likely makes the point moot).

> 2. I have created two SocketLocator types (one for names to be looked 
> up
> by DNS and one for IP addresses).
>
> My idea was to eliminate a call to gethostbyname if it isn't necessary.
>
> I suppose calling gethostbyname is irrelevant in terms of speed and
> maybe it's best to call it anyway.

Having extra options is always helpful. In the new version of the code, 
things are clearer and the cost of this extra option should seem 
somewhat less to you.

> 3. I haven't implemented any error handling. How do we pass the error
> information from C-space to Slate-space and give a meaningful 
> condition?
> How do we do this for multiple UNIX platforms (I assume error values 
> may
> be different).

Most likely we'll need to define our own mapping.

> How do we integrate error conditions with win32?

This is a larger issue. The Squeak fellows haven't tackled it, nor 
anyone else I'm aware of. There is an SDL_Net package that offers 
cross-platform sockets, but I'm unsure if they address this issue or 
avoid it.

> 4. Some of the code is quite ugly, please suggest fixes if you think I
> am missing a concept which would yield cleaner code.

I've done this. I don't think diffs would help much to explain, since I 
changed nearly everything, but a side-by-side comparison per method 
would probably help you. As I said above, I just altered it to fit the 
style used for the console code.

> 5. I have implemented ReadIntoXX and WriteFromXX methods, but perhaps
> these are the same as existing primitives?

Well, it seems to work, since your test uses a WriteStream on the 
socket.

--
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/




More information about the Slate mailing list