[Gcl-devel] Re: sock_get_string_buf

[Camm Maguire]

Greetings!

Waldek Hebisch <address@hidden> writes:

> > Greetings, and thanks so much!
> > 
> > Waldek Hebisch <address@hidden> writes:
> > 
> > > I again had problem with "sock_get_string_buf": trying to use hypertex
> > > functions which require Axiom (for example search or tutorial input)
> > > gives:
> > > 
> > > (1) ->
> > >    >> System error:
> > >    Unexpected end of #<string-input stream from "                ...">.
> > > 
> > > Recent patch to gcl fixed the problem on many machines. But on one
> > > machine (using 2.4.31 kerenel) I was still getting this error.
> > > 
> > > So I tried the patch below and it solved the problem.  AFAICS the
> > > problem is that GCL string parameter wants to preserve string
> > > _value_, but what Axiom want is pass by reference.  My undersanding
> > > is that GCL has full right to copy the string, so the only relaiable
> > > solution must use 'object' type and extract string address from it.
> > > 
> > > Remark1: It seems that "official" GCL foreign function interface is
> > > is very incomplete for real world needs. I would suggest either
> > > promoting 'object' structure as documented, official low level
> > > interface, or adding few more arguments types (mostly arrays by 
> > > reference).
> > > 
> > > Remark 2: This may be related to Debian bug 328480 (but what Camm
> > > wrote seem indicate different problem).
> > > 
> > 
> > This indeed fixes the above -- thanks!  Some axiom code must be
> > declining do write to a copied buffer or some such.
> > 
> > May I suggest adding
> > 
> >           "   if (x->st.st_fillp<j) FEerror(\"string too small\",0);"
> >
> 
> Yes, good idea.
>  
> > to the wrapper.  In general, we might want a non-null terminated
> > buffer type of a given length in the C interface too.  I'm guessing
> > this is what you mean by arrays by reference.  Documenting object is a
> > good idea too.
> > 
> 
> Typical uses I can see are:
> 
> 1) calling operating system.  This typically uses scalars and strings,
>    but may require structures.
> 2) calling numerial librarires.  Such librarires typically operate
>    on floating point arrays, but may also need integer arrays.
> 
> While support for C structures would be nice, one can use arrays
> of apropriate size and use Lisp byte operations to emulate C
> structures.  OTOH direct support for arrays seems essential.

There was another axiom user of late who implemented a GCL blas/lapack
interface within axiom.  It is fairly straightforward, but one needs
to make sure the arrays are static.  One can ensure this by checking
that the address is < heap_end.  Even though these external routines
do not call lisp, nor do they store references across calls, static is
still needed as they call malloc, which GCL redirects to protect
itself, and which can therefore trigger a gc.  I believe the same
logic should apply to the axiom socket code.  If 1) no pointers are
stored across calls 2) no lisp callbacks are made 3) no heap
allocation is made (alloca is OK), then relocatable pointers are fine.
Of course if one can use relocatable, it is better, as it is faster.

(On Debian, BTW, one can compile and load a simple defentry
blas/lapack api, call compiler::link adding -lblas -llapack -lg2c to
the command line, and then run the new image against whatever
optimized atlas library that might be available without
recompilation.)

We went through this with GMP bignums.  We had to implement a special
GC escape mechanism within GMP calls to protect the much faster
relocatable bignum algorithm.

Take care,

> 
> > Last comment -- GCL stores strings by default in relocatable memory --
> > i.e. they are copied at each gc.  This is much faster.  An immovable
> > type in 'contiguous" memory is also an option, via
> > 
> > (make-array 10 :element-type 'character :static t)
> > 
> > If axiom needs these pointers not to move across gc, may I please
> > suggest using the latter.  I've already checked, the pointers in use
> > are relocatable.
> > 
> 
> AFAICS C code does not store pointers to Lisp data (and there are no
> callbacks from C to Lisp). If (as I hope) GCL will not trigger garbage
> collection form a signal handler, keeping strings in relocatable memory
> should be safe.
> 
> -- 
>                               Waldek Hebisch
> address@hidden 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah