Forum OpenACS Development: Re: ANNOUNCE: NaviServer 4.99.8 available
With recent versions of NaviServer, most of the usages of bg-delivery can be replaced by "ns_writer submitfile ..." when writer-threads are in use (look for use_writerThread in ). The writer threads are roughly the equivalence of the bgdelivery thread, but implemented in C, not relying on select(), are lightweight in memory use and fast (using the common io-machinery of NaviServer). For the introduction to the async support in NaviServer, see section "2.3. Asynchronous Architecture" in .
In fact, when one is using a recent version of xotcl-core, ad_returnfile_background uses automatically the writer threads, no application code changes are needed. we use this since a while on our production systems an on openacs.org.
Actually, the only place were we are still using - and that might be the source of your interest - is the h264 streaming code. It should be actually not hard to replace there the tcl/io (e.g. replace "puts -nonewline $channel ..." by "ns_connchan write $channel ...", use "ns_connchan callback ...", etc.). This has as well the advantage that it will work without changes with tls. When one wants to copy the fd from a channel, this would defeat this purpose. So far, i had no time to look into the details to implement h264 delivery via ns_connchan.
To see ns_connchan in action, look at the WebSocket code in .
We use the h264 delivery mechanism less and less these days ourselves, but we never actually used ad_background_returnfile for the purspose. Instead we've simply got a tcl thread handling the reading and writing. HTML5 and byte ranges have decreased the use of this drastically though.
Concerning ad_returnfile_background: it has the same interface like ns_returnfile. The changes for NaviServer in OpenACS are mostly due to using features of NaviServer not available in aolserver. If you get a recent version of OpenACS (e.g. the tar file), just grep for NaviServer, these should be pretty easy applicable for every OpenACS mutant.