functionality of Socket>>socketError
John Pfersich
jp1660 at att.net
Wed Aug 25 17:46:35 UTC 2004
I'd like to make a suggestion to the VM maintainers. It would be
nice to get the actual error message back from the OS, but one that
would be platform independent, so that a developer could, if they
choose, try to recover from the error.
For example, the C macro ECONNREFUSED is mapped to 61 on OSX, 111 on
Linux, and 146 on Solaris; and ETIMEDOUT is mapped to 60 on OSX, 110
on Linux, and 145 on Solaris.
(sorry, no Windows examples, I've not coded in Windows since the early 90's.)
I think it would be nice to have a new primitive that returns a
platform independent code instead of the raw error code. Then we
could add a new method that gives the developer access to that value.
As an aside to Kamil Kukura, you might want to use the message
statusString for now, I think it might work better than socketError
does for now.
>I'll be the first to say this is all a bit ill defined. You really
>need to check the C source code for the socket support code to
>understand what is happening.
>For os-x on or after the carbon VM 3.5.1b2 we switched to the Unix
>BSD socket code. The socketError primitive returns the results of
>capturing errno, or
> getsockopt(s, SOL_SOCKET, SO_ERROR, (void *)&error, &errsz)
>depending on what is happening at the time. This all assumes us VM
>folks capture the error data and don't have multiple calls trashing
>things (accept processing comes to mind).
>
>Really one needs to review the C source code for the called
>primitive at the time of the error is required to understand where
>the data comes from.
>
>On the other hand, sticking some documentation in the
>Socket>>socketError could be useful.
>--
>======================================================================== ===
>John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
>Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
>======================================================================== ===
--
----------------------------------------------------
Source code in files. How quaint. -- Kent Beck
More information about the Squeak-dev
mailing list
|