[usocket-devel] Re: usocket backend/allegro.lisp

[Robert P. Goldman]

Erik Huelsmann wrote:
> On 1/22/07, Robert P. Goldman <rpgoldman at sift.info> wrote:
>> Erik Huelsmann wrote:
>> >
>> >> Ah, I see that this file is fixed in the subversion repository --- at
>> >> least to the extent that it loads correctly.
>> >
>> > You mean cl-irc still doesn't work for you?
>> >
>> > Yes, cl-irc works with SBCL: I have a 0.8.0 image running for some
>> time now and haven't seen any problems.
>>
>> I got it to crash a couple of times.  Per your suggestion below, this
>> was in a case where Allegro returned a NIL value for a socket.
>> >
>> > As far as documentation on the functions in allegro.lisp: for all
>> methods and most functions, there's documentation in usocket.lisp. If
>> that's insufficient, no problem, but I'll need directions on what's
>> unclear so I can add it.
>> >
>> > Looking at the sources, usocket doesn't account for the case when a
>> NIL socket is returned by Allegro. I guess usocket should return NIL
>> when Allegro does (and cl-irc should take into account NIL is a valid
>> return value signalling 'no socket').
>> >
>> > Do you have any idea what could have gone wrong so that no socket
>> was created?
>>
>> Not really.  BEIRC got all bollixed up because I was already logged into
>> freenode using my usual nick.  It doesn't seem to rollover from the
>> prespecified nick that happily.
>>
>> I will see if I can replicate the behavior.
>>
>> Should usocket return nil in this case, or raise an error?
> 
> That's a good point. Well, I guess it should raise an error: the
> interface contract specifies it to return a socket and the interface
> contract for the returned socket is to contain an implementation
> defined socket reference. Since we can't return a valid socket, I
> guess socket-connect should raise 'unknown-error...

I think that's right, as well.  The problem with the current behavior is
that the actual crash (when some code attempts to do something with the
alleged socket of NIL) can come at an arbitrary distance from the actual
error (returning NIL instead of a socket), making code that uses usocket
more difficult to debug than necessary.

Should there be a more specific error class??
> 
> Having replicated behavior would be great! That way I'd be able to
> check for the same behavior in the other backends (and maybe in other
> allegro versions).

OK, I'll see what I can do.  I was flailing around with beirc, so I may
not be able to replicate this that easily (and, of course, a simple
invocation of cl-irc, w/o involving beirc would make a better test case).

Best,
R


-- 
Robert P. Goldman
Senior Scientist
Smart Information Flow Technologies (d/b/a SIFT, LLC)

211 N. First St., Suite 300
Minneapolis, MN 55401

Voice:	(612) 384-3454
Email:    rpgoldman at SIFT.info