site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=KXZWR4Q5nDSENL3qJrwpObmVGH6lO5joV6X+ivjbYGLnFoQK/VM8w7uCYKk1OJ/L9PDczKHZCl2uIpwbod4ZDpF+bjo4pD4jHOw4Q/XYwc+GoSRl0xDrSflxgdLEk+0Gm625Vn8c3NQvSJW0erYkjHOaOQGyvSE1HPlmIvtJf9M= Consider this an educational question for now. I'm considering switching things back to the way they were before, which aleviates the problem ... and thus the need for a solution, but I'm still interested in what's going on in the kernel. My observation is that there is a difference between threads associated with user processes and those "spawned" by a call to bsd_timeout(). There is this lengthy (~15 seconds) calculation that takes place in response to input from the user app. In a previous version of this program, that happened directly within the thread associated with the user process which called send() to give some input to the kernel extension. The effect was that send() blocked for those ~15 seconds but the rest of the system behaved normally. When this same calculation takes place within a thread "spawned" by bsd_timeout(), the whole system[1] seems to lock up. I can't even move the mouse. Anyway ... can anyone articulate the difference? -Curtis [1] It appears that once or twice the WindowServer gets to update the window a bit. The button that starts this process changes color to reflect the release of the mouse after a few seconds. Very slow. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com