i was a few days offline, so sorry for my delayed reply.
I am telling this because I just completed the ns_http rewrite that handles more/less similar issue w.r.t queued http reads/writes and I was using the same cut/splice technique to open a channel in one and read/write to it in the other thread. In order to keep this option open and not to clutter the Tcl API, the "ns_asyncwrite" should allow for ns_asyncwrite ?-channel chan | -fd fd? content At some time, if needed, the writer can be expanded to understand Tcl channels as well.
OK. Back-off. That would never work that way.
The problem with Tcl channels is that these (including their buffer management) are per-tcl-interp structures, and since different threads use different Tcl-interps Tcl channels are not multi-thread friendly. Therefore, the previously mentioned, Tcl-based background writer used in OpenACS since many years is based on a special Tcl thread (implemented via Tcl's libthread), where the file is opened by sending the open command to this thread, and the thread can do arbitrary Tcl file operations like in single threaded applications. But, every "write" operation from other threads triggers a send operation to this Tcl-thread, which performs the operation. This works very well within the previously mentioned limits. But also in these cases, async write operations are essentially fire-and-forget. When looking on reusing NaviServer's AsyncWriter thread, providing an interface on the numeric file descriptors looks still the best option to me. If we would base the async-write operation on a Tcl channel (as you mentioned earlier) this would not work when multiple threads/Tcl interps write to the same file, since the different interps have different channels, fds, etc.. Furthermore it make me shudder, when other Tcl operations would happen on this Tcl file handle.
As I see, this could only work for "fire-and-forget" cases were one is not interested in any result and where one is producing small amount of data to be written.
The whole thread was started with such an assumption. I have implemented the (optional) AsyncWriterThread in NaviServer exactly with these assumptions for disk-write operations back in 2013 - 4.99.5, we are using it on our high traffic sites since this time without a single problem (for the access.log and error.log). Btw, the AsyncWriterThread handles partial write operations. But if ask me, if i would write life-critical information this way, i would say that async disk writing would not my first choice. OTOH, the C based implementation is imho much more robust and simple than the Tcl base approach I've implemented for OpenACS, so this is an advantage. So, providing access from the Tcl level makes sense. But you are right, one should not raise expectations to high on this, so using more specialized names is probably better ns_asynclog_open ns_asynclog_write ns_asynclog_close I think, it costed me less time to write this email than to implement these wrapper calls, since the base infrastructure is already in NaviServer. Zoran, if you think, such naming measures are not enough, i can make a few calls external and implement these wrappers as a module (biggest disadvantage: configuration and change management, build and install scripts for projects using it.... such as OpenACS, etc.) all the best -g _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
