Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 3 Jan 2003 13:52:18 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 3 Jan 2003 13:52:18 -0500 Received: from fmr01.intel.com ([192.55.52.18]:28116 "EHLO hermes.fm.intel.com") by vger.kernel.org with ESMTP id ; Fri, 3 Jan 2003 13:52:18 -0500 Message-ID: From: "Grover, Andrew" To: Pavel Machek , ACPI mailing list , kernel list Subject: RE: [ACPI] acpi_os_queue_for_execution() Date: Fri, 3 Jan 2003 11:00:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-8859-1" Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1130 Lines: 29 > From: Pavel Machek [mailto:pavel@ucw.cz] > Acpi seems to create short-lived kernel threads, and I don't quite > understand why. > > In thermal.c > > > tz->timer.data = (unsigned long) tz; > tz->timer.function = acpi_thermal_run; > tz->timer.expires = jiffies + (HZ * > sleep_time) / 1000; > add_timer(&(tz->timer)); > > and acpi_thermal_run creates kernel therad that runs > acpi_thermal_check. Why is not acpi_thermal_check called directly? I > don't like idea of thread being created every time thermal zone needs > to be polled... Are we allowed to block in a timer callback? One of the things thermal_check does is call a control method, which in turn can be very slow, sleep, etc., so I'd guess that's why the code tries to execute things in its own thread. Regards -- Andy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/