[Openmcl-devel] Transfer the contents of a file to a tcp stream

[Richard Newman]

> Well, even without the setup/teardown of the this OpenMCL will hardly
> erver reach Apache (BTW, how would teardown affect the measured time?).

It would depend on when wget stops timing, I suppose! :D

It's a long time since I did any low-level networking stuff, so to be 
honest I don't even remember if the client and server have to sign off 
a connection.

The setup was the main thing I was thinking of; if I served a 2.5MB 
JPEG over a loopback with Araneida, or using CGI, then it's quite 
likely that the handler generic function (or the CGI startup) would 
double the time compared to Apache poking a thread. A 700MB ISO might 
be another matter entirely.

> When sending _files_ (not content from memory) Apache tries hard to
> use a sendfile(2) or  similar techniques (depending on the underlying 
> OS).
> When sendfile is used the kernel is instructed to copy (send) a file 
> directly
> from one file descriptor to another. First of all, with this trick data
> never has to cross the (expensive) border between kernel space and 
> userspace
> (as opposed to crossing it twice in the OpenMCL sample code). On a 
> reasonably
> smart OS that data might even never pass the kernel but travers via 
> DMA from
> disk to network card.
> Of course, since OpenMCL has a nice FFI interface it would be trivial 
> to
> call sendfile from it .... but that would be cheatin' :-)

It might be fun to write a trivial-http style library to do TCP file 
transfers, using sendfile if possible but otherwise falling back to 
pure CL...

Christian might well have run into the theoretical limit for a CL 
userspace program!

-R
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2367 bytes
Desc: not available
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20050503/267776aa/attachment.bin>