From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jason Rumney Newsgroups: gmane.emacs.devel Subject: Re: Patch to trunk: merge common code in hourglass impl Date: Wed, 04 Jun 2008 22:31:28 +0100 Message-ID: <484709B0.9060804@gnu.org> References: <484660F1.2070609@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1212615114 25910 80.91.229.12 (4 Jun 2008 21:31:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 4 Jun 2008 21:31:54 +0000 (UTC) Cc: adrian.b.robert@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 04 23:32:35 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1K40ax-0000Er-CW for ged-emacs-devel@m.gmane.org; Wed, 04 Jun 2008 23:32:35 +0200 Original-Received: from localhost ([127.0.0.1]:47258 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K40aA-0006qV-TV for ged-emacs-devel@m.gmane.org; Wed, 04 Jun 2008 17:31:46 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K40a6-0006qF-T9 for emacs-devel@gnu.org; Wed, 04 Jun 2008 17:31:42 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K40a4-0006q3-CH for emacs-devel@gnu.org; Wed, 04 Jun 2008 17:31:41 -0400 Original-Received: from [199.232.76.173] (port=57499 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K40a4-0006q0-6I for emacs-devel@gnu.org; Wed, 04 Jun 2008 17:31:40 -0400 Original-Received: from mk-outboundfilter-5-a-2.mail.uk.tiscali.com ([212.74.114.4]:17753) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K40a0-0003CH-0f; Wed, 04 Jun 2008 17:31:36 -0400 Original-X-Trace: 38674155/mk-outboundfilter-5.mail.uk.tiscali.com/F2S/$ACCEPTED/freedom2Surf-customers/83.67.23.108 X-SBRS: None X-RemoteIP: 83.67.23.108 X-IP-MAIL-FROM: jasonr@gnu.org X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYEADmmRkhTQxds/2dsb2JhbACBVa88 X-IronPort-AV: E=Sophos;i="4.27,591,1204502400"; d="scan'208";a="38674155" X-IP-Direction: IN Original-Received: from i-83-67-23-108.freedom2surf.net (HELO wanchan.jasonrumney.net) ([83.67.23.108]) by smtp.f2s.tiscali.co.uk with ESMTP; 04 Jun 2008 22:31:32 +0100 Original-Received: from [192.168.249.27] (chiko.jasonrumney.net [192.168.249.27]) by wanchan.jasonrumney.net (Postfix) with ESMTP id 74CA72EC; Wed, 4 Jun 2008 22:31:31 +0100 (BST) User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) In-Reply-To: X-Enigmail-Version: 0.95.6 OpenPGP: id=8086879D X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:98427 Archived-At: Eli Zaretskii wrote: > Yes, atimers work by sending SIGALRM, which isn't supported on > Windows. While Windows has equivalent functionality, no one stepped > forward to emulate atimers, probably because their use in Emacs is > quite limited, and in areas where Windows offers alternate ways of > doing the same. > What is the equivalent functionality? Threads are not the same as signals, as they do not block other threads from executing. This is a problem when any Lisp code is run, as a GC can occur in the main Lisp thread while the signal emulation thread is running Lisp code, leading to memory corruption and crashes. So any system timers need to be handled in the Lisp thread, which effectively means they are synchronous. Since the hourglass code doesn't actually need to run Lisp, I used a Windows system timer running in the UI thread, which is not generally busy enough to have delays like the Lisp thread, but I don't think a general atimer implementation can be done that way.