> For lptclose, note that callout_stop does not wait for the callout to > stop if it was in the middle of executing, and does not destroy it. > You must use callout_halt to wait, and then use callout_destroy to > destroy it.
Okay, manpage bug - 5.2's callout(9) does not mention callout_halt (though it exists in <sys/callout.h> and sys/kern/kern_timeout.c), so I was not aware of it. I should probably fix the manpage. (Also, its second argument is typed as void * rather than kmutex_t *. Weird.) I think I found the actual problem. My write routine was missing a break condition, so it was infinite-looping in kernel mode with the giantlock held, thereby blocking practically everything. (I found this by keeping a trace of line numbers in a ring buffer, for dumping with ddb; once I added that tracing to the write routine it became obvious. And, once noticed, it's obvious in the code too. And, if I'd thought it through propertly, I'd've realized that my userland test program doesn't yet do reads, only writes, so, while the callout ticker was perhaps relevant, the read routine couldn't've been because it was never getting called.) I was focusing on the callout/mutex stuff because it was the piece I felt experimental about. Perhaps I should have used sleep/wakeup until I had it working that way and then switched - "first make it work, then make it better". Thus, turns out most of the condvar/mutex stuff was a red herring. But 'twas not wasted, as I fixed at least two bugs waiting to happen and have a significantly better understanding of this stuff thanks you people! And, now, when I try to read (which I eventually will need to do), it has a fighting chance of actually working. In case anyone cares, I've dropped my latest version (I just rebuilt and am about to test it) in a new2/ directory in the anonymous ftp area I mentioned upthread. Many thanks once again. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B