[Axiom-developer] Re: puzzled....

[Chris Hall]

root <address@hidden> writes:

> in o/object.h (line 350) there is the struct:
> 
> struct ustring{ 
>   ....
>   unsigned char *ust_self;
>   ....
> 

Just above it (line 336) is 'struct string' - the only difference I
can see between the two structs' members type-wise is the definition
of the char pointer.

My C is pretty rusty, but I guess it is pretty safe to bet that the
pointer size for these types *ought* to be the same on all
compilers/platforms, so that sizeof(struct ustring/string) *ought* to
be the same - though one can never be absolutely 100% sure of this,
IIRC. ;-)

> this appears to be the definition of ust_self, a pointer to a char *array
> 
> 
> 
> in gcl-tk/sheader.h (line 109) OBJ_TO_CONNECTION_STATE(x) is defined as
>   
> #define OBJ_TO_CONNECTION_STATE(x) \
>   ((struct connection_state *)(void *)((x)->ust.ust_self))
> 
> so it appears that OBJ_TO_CONNECTION_STATE accepts a thing of type
> ustring and casts the (char *)array to a (connection_state *)array
> 
> 
> yet in sockets.c (line 330) the macro is used with an argument:
>  .... (OBJ_TO_CONNECTION_STATE(fd) .....
> where "fd" has been used to indicate the "file descriptor" which
> is a fixnum.

DEFUN_NEW("OUR-READ-WITH-OFFSET",object,fSour_read_with_offset,SI,5,5,NONE,
OO,OI,II,OO,(object fd,object buffer,fixnum offset,fixnum
             ^^^^^^^^^

As a guess, since it isn't a fixnum, given the context it might very
well be meant as an 'sfd'/connection_state (see below)?

> 
> Further the buffer it tries to write into needs to be of type ustring.
> 
> I have 2 questions:
>   (a) should sockets.c line 330 read:
>        ... (OBJ_TO_CONNECTION_STATE(sfd) ...
>        (which means that the argument to the function must change)
>   
>   (b) how does one allocate a ustring?

Based on my guesses above, I would guess further that
'alloc_simple_string(int l)' found in o/string.d at line 37 - and
which seems to alloc a struct, actually ;-) - is what is being used:
the st_dim member is set to l, and st_self set to the address of the
actual string, storage for which seems to have been allocated
elsewhere.

As for 'sfd', from what I can see it would seem that it is used to
refer to the connection_state struct itself, here and elsewhere - one
of the reasons I looked into this is because I, too, was curious about
this usage.

(I suspect that t_string is part of an enum somewhere, but I haven't
yet located where t_string is defined.  If someone knows, please
share?)


(DISCLAIMER: the following is more general and usage-related.)

In ACCEPT-SOCKET-CONNECTION (in o/sockets.c line 210) a string struct
for sizeof(connection_state) is allocated and set to (a pointer to)
the contents of setup_connection_state(fd) (in gcl-tk/comm.c line 69).

connection_state is a struct (in gcl-tk/sheader.h line 86) that
contains the fd for the socket, a pointer to a char buffer or two,
transmission byte counts, etc.

Oh ho!  So that bizarre looking the string in the car of the result
from ACCEPT-SOCKET-CONNECTION is the *connection_state/sfd*.

Here is a transcript of using some of this:

--------------- snip --------------------
>(setf skt (si::open-named-socket 0))
(3 . 5000)

>(setf skt-conn (si::accept-socket-connection skt))
(("

3 . 5000)

>(si:connection-state-fd (car (car skt-conn)))
4
--------------- /snip -------------------
Ummm, could anybody explain to me why the fd's are different in the
previous example?

It seems that I can only open a socket on the localhost (I know that
SI::SOCKET eems to work with another host)?

Can anyone tell me if the following sequence is the correct procedure
to follow when I am done with a socket connection?
--------------- snip --------------------
>(si:close-sd (car (car skt-conn)))
NIL

>(si::close-fd (car (cdr skt-conn)))
T
--------------- /snip -------------------

If I do this, it *does* seem to solve the 'CLOS_WAIT/FINL_WAIT'
problem I described in an earlier post.


Aloha,
+Chris

-- 
Good judgment comes from experience. Experience comes from bad
judgment.
- Jim Horning