Re: serving a file to a client --- background fcopy read fileevent event puts socket channel blocking nonblocking

On Mar 29, 2:08 am, vit...@xxxxxxxxx wrote:
But, nevertheless, lets attempt to go after a solution that does not
use threads.

Yes, it makes sense to try at least.

How do you write a file to socket copy procedure that notifies me
about it's progress every so many bytes and does not block while doing so.

Easy: use [fcopy -size ... -command ...]
The callback will of course have to repost the fcopy for the next
chunk until eof.
All this orchestrated by a single [vwait forever], no [while] loop.

If you have already tried this and encoutered problems, please explain
and possibly post them into the Tracker.

How about if I want to control how fast
the copy progresses without blocking other events?

Easy: instead or reposting the fcopy, the callback does [after
$somedelay repost].

Thanks
Those are just theoretical questions that need generic answers.

They do have very simple answers based on [fcopy] as you can see, at
least theoretically.
If in real life [fcopy] is not up to the promise, *that* is the single
most urgent thing to fix in the whole Tcl core, instead of reinventing
that wheel over and over again.

Of course, it is possible to reimplement [fcopy] in pure Tcl, and it
even is a good exercise for whoever wants to learn about the event
loop. But this will never have the performance of [fcopy], which is
documented as "leverag[ing] the buffering in the Tcl I/O system to
avoid extra copies and to avoid buffering too much data in main memory
when copying large files to slow destinations like network sockets".

-Alex
.

Relevant Pages