On Fri, Dec 19, 2008 at 8:55 AM, Christian Magnusson <m...@mag.cx> wrote:
> > I noticed one "problem" at once when cleaning up the processes... > There are no process-list and pthread_cancel() is never called to stop all > running threads when you press Ctrl-C. > This means that one thread has locked the connection_out->accept_mutex, and > the FreeOut() function fails to destroy this mutex. > > [r...@magpc owfs]# /opt/owfs/bin/owserver --nozero -p 5001 --fake 10,28 > --foreground --fatal_debug > ^C > DEFAULT: ow_connect.c:322 DEFAULT: mutex_destroy failed rc=16 [Device or > resource busy] > > It's not any big problem, but we should perhaps have a list of all running > threads and try to free all resources a bit cleaner. > > What do you think Paul? Isn't it worth to have better control over all > running threads? > So normal process clean up doesn't reap all the threads? I've noticed some problems when threads are waiting in select calls and a SIGINT (^C) is sent. OWFS is pretty heavily threaded, so keeping track would be a bit of work. A listen thread waiting for queries in owhttpd, owserver and owftpd (owfs does the same thing in the FUSE library) (per tcp address) 1 thread per active query (accept) plus a preallocated few. 1 thread per bus on directory and presence processing. A timeout thread in owftpd A netlink monitoring thread for the w1 module A thread each for zeroconf announcements and browsing In most cases the threads are detached.
------------------------------------------------------------------------------
_______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
