From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <200509211325.j8LDPU929905@zamenhof.cs.utwente.nl> To: 9fans@cse.psu.edu From: Axel Belinfante Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Sep 2005 15:25:30 +0200 Subject: [9fans] thread confusion Topicbox-Message-UUID: 8d63dd08-ead0-11e9-9d60-3106f5b1d025 I've been wrestling with the thread library trying to do resource management in my 802.1x thingy. This has proven to be harder than I envisioned - I guess I've been spending more time trying to get this right (I want this right since it may run as a daemon for a long time, doing a new tls handshake every 20 minutes or even more often) than I think I've spent on the protocol/state machine part :-( One reason may be that I'm still not very experienced with thread(2). Another may be that weird things are happening. A/The main weird thing is that after doing threadint on a thread (created with proccreate) which presumably is hanging in a read sometimes(?) the process just disappears without leaving a trace, even though it is packed with syslog calls (of which only the first part gets executed). Actually, it does leave a trace, because when invoking acid on the main process and doing threads() or stacks() acid complains that setproc cannot read /proc/XXX/mem where XXX presumably was the pid of the disappeared process. (this seems to suggest that also the thread administration was not aware of the thread/process dying?) This is hard to track since I'm not really able to reproduce it, though I may be able to detect it when it happened. Any ideas of what might be going on here, or how to debug this? Another weird thing (bug?) is that threapid always returns -1 (I started looking a bit into this, but maybe someone in the know sees the problem immediately) (furthermore thread(2) and thread.h seem to be inconsistent regarding return values of (e.g.) threadint*, threadkill* but this is not hard to fix; I could/can submit a patch) Axel.