gtravan@sirius.ua.oz (George Travan) (02/27/89)
could someone provide some demo code which demonstrates a mechanism whereby a
C Client could pass arrays of data (particularly floating point) to a Server?
I seem to have quite a few problems trying to do this successfully.
--george travan
ACSNET: gtravan@sirius.ua.oz
or george@frodo.ua.oztim@capmkt.UUCP (03/02/89)
>>> could someone provide some demo code which demonstrates a mechanism whereby a >>> C Client could pass arrays of data (particularly floating point) to a Server? assuming you already have the connection to the server you could do it like this: /*** the c function ***/ send_valarray() double vals[]; { int i; arraystart(); for(i=0;i<NUMVALS;i++) emit_double(vals[i]); arrayend(); } /*** the cps defs ***/ cdef arraystart() [ cdef arrayend() ] cdef emit_double(double val) val /************************************/ tim edwards capital market technology, inc. 1995 university ave, suite 390 berkeley, ca 94066 tim@capmkt.com or ...!uunet!capmkt!tim
paul@ppgbms (Paul Evan Matz) (03/06/89)
In article <8903010054.AA06125@bill.capmkt.com> tim@capmkt.UUCP writes: > >/*** the cps defs ***/ > >cdef arraystart() > [ > >cdef arrayend() > ] > >cdef emit_double(double val) > val > You might want to build into the cdef functions the array identifier assignment part too, like: cdef arraystart() ArrayDataName [ cdef arrayend() ] def One *VERY* big problem with this method is that the array data is being put on the stack of the server side liteweight process, so if you're trying to pass an array bigger than 1000 words, look out for a stack overflow! (I've heard there is a way to increase the stack size, but have never found out how). Another problem with this method is that the data being passed is translated into ascii by the client, sent on the byte stream connection to the server, who then translates it back to binary whatever. Kinda slow. Depending on what you are doing with the data, it is sometimes better to use some of the cdef intrinsics like ps_moveto, ps_lineto; I think the passed parameters are tokenized in an XDR-like way (I can't remember where I read this. I could be completely off base on this, but I don't think so). Maybe Sun will provide a decent binary array transmission mechanism in the X11/NeWS merge. Anybody care to comment? Paul Matz PPG Biomedical Systems One Campus Drive Pleasantville, NY. 10570 914-741-4685 path ppgbms!moe!paul@philabs.philips.com
owen@SUN.COM (Owen Densmore) (03/07/89)
One *VERY* big problem with this method is that the array data
is being put on the stack of the server side liteweight
process, so if you're trying to pass an array bigger than 1000
words, look out for a stack overflow! (I've heard there is a
way to increase the stack size, but have never found out how).
The stack can be avoided by using an executable array:
cdef arraystart()
ArrayDataName {
cdef arrayend()
} cvlit def
The cvlit converts this back to a vanilla array. The stack does not
get used to create the array; the scanner takes care of it for you.
Owentim@capmkt.UUCP (03/07/89)
ppgbms!moe!paul@philabs.philips.com writes: >>One *VERY* big problem with this method is that the array data is being >>put on the stack of the server side liteweight process, so if you're >>trying to pass an array bigger than 1000 words, look out for a stack >>overflow! (I've heard there is a way to increase the stack size, but >>have never found out how). there is apparently a workaround for this. after i had posted the original method, a fellow from sun (i believe it was <owen@sun.com> but i have lost the original message) sent me tip saying that if you use executable arrays, then the stack is not used at all. so changing the code to read cdef arraystart() { %%% instead of [ cdef arrayend() } %%% instead of ] should solve the stack-overflow problem. if anyone understands the magic behind this, i would be interested in knowing how/why this works. tim edwards capital market technology, inc. 1995 university, #390 berkeley, ca (415)540-6400 tim@capmkt.com or capmkt!tim@uunet.uu.net