From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Elisp native profiler Date: Tue, 25 Sep 2012 13:28:37 -0400 Message-ID: References: <83zk4egs0w.fsf@gnu.org> <83y5jygrni.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1348594144 25385 80.91.229.3 (25 Sep 2012 17:29:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Sep 2012 17:29:04 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 25 19:29:05 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TGYwM-00078a-Qj for ged-emacs-devel@m.gmane.org; Tue, 25 Sep 2012 19:28:58 +0200 Original-Received: from localhost ([::1]:56400 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGYwH-0005Ri-OV for ged-emacs-devel@m.gmane.org; Tue, 25 Sep 2012 13:28:53 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:39166) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGYwC-0005QC-6P for emacs-devel@gnu.org; Tue, 25 Sep 2012 13:28:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TGYw8-0001Xn-7X for emacs-devel@gnu.org; Tue, 25 Sep 2012 13:28:48 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:53572) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGYw6-0001Vd-JO; Tue, 25 Sep 2012 13:28:42 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu09FpZV1/2dsb2JhbABEtBGBCIIVAQEEAVYjBQsLNBIUGA0kiBwFugmQRAOjM4FYgwWBQw X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="199947275" Original-Received: from 69-165-149-117.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([69.165.149.117]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 25 Sep 2012 13:28:37 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 9DE02AE73A; Tue, 25 Sep 2012 13:28:37 -0400 (EDT) In-Reply-To: <83y5jygrni.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 25 Sep 2012 15:26:25 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:153537 Archived-At: [ Sorry, I hit C-c C-c by mistake in my previous email. ] > Btw, doesn't sigprof_handler in profile.c violate the SYNC_INPUT > paradigm, by running non-trivial code which can allocate memory from a > signal handler? sigprof_handler is written in such a way that it doesn't allocate any memory, so while it runs non-trivial code, it doesn't make any system-call or anything like that, it doesn't modify any data reachable from the rest of Emacs code, and neither does the rest of Emacs code modify any of the data it uses (except for a few global vars like cpu_log, and I believe these don't suffer from race-conditions, but I'm not very good at detecting those problems). > Shouldn't profiling use the same framework as atimers > and the other async events? We could do that, but to the extent that it is possible to do all the work in the signal_handler while still being safe, I think it's preferable. Most of the work done in the other signal handlers are inherently "unsafe in the handler" because they really need to make syscalls. Stefan