From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: x-display-pixel-width/height inconsistency Date: Fri, 10 May 2013 16:47:36 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <514A5DE1.10009@gmx.de> <831ub767wf.fsf@gnu.org> <83mwtu4p7c.fsf@gnu.org> <83vc8h313t.fsf@gnu.org> <5073D6B8-95E4-4012-AA74-106F428379DC@swipnet.se> <8BD4B041-5A3F-4D7C-AFD3-E997E194AA9D@swipnet.se> <02B98FCD-71DB-47EC-B58B-41A2539FF61A@swipnet.se> <83vc6tcqss.fsf@gnu.org> <83haibdipo.fsf@gnu.org> <837gj7co0l.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1368172070 29225 80.91.229.3 (10 May 2013 07:47:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 May 2013 07:47:50 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 10 09:47:49 2013 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 1Uai3Q-0001Tg-G0 for ged-emacs-devel@m.gmane.org; Fri, 10 May 2013 09:47:48 +0200 Original-Received: from localhost ([::1]:37379 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uai3Q-0001ox-5s for ged-emacs-devel@m.gmane.org; Fri, 10 May 2013 03:47:48 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51386) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uai3K-0001kD-Ii for emacs-devel@gnu.org; Fri, 10 May 2013 03:47:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uai3I-0007az-OR for emacs-devel@gnu.org; Fri, 10 May 2013 03:47:42 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:52385) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uai3G-0007a7-Lf; Fri, 10 May 2013 03:47:39 -0400 Original-Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 92C18C055D; Fri, 10 May 2013 16:47:36 +0900 (JST) In-Reply-To: <837gj7co0l.fsf@gnu.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 133.82.132.2 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:159469 Archived-At: >>>>> On Fri, 10 May 2013 10:06:18 +0300, Eli Zaretskii said: >> > It makes me nervous to have consing inside a Win32 API callback. Are >> > we even sure the callback gets called in the context of our main >> > tread? If not, and if consing causes GC, we could blow up the stack. >> >> If the callback can be called from the thread/context other than the >> one for EnumDisplayMonitors and that can cause memory synchronization >> issue, then API documentation should clearly say so, because such kind >> of problem can happen even with other data structures. > Well, we can sue MS, but that won't help us, I think. > Seriously: while debugging Emacs on Windows, I frequently see messages > from GDB about new threads being launched, which I know for sure Emacs > didn't do directly. I have no idea why they are started. For > example, calling GetOpenFileName certainly starts a new thread, but > the MSDN documentation says nothing about that. (We've had problems > with the stack size of that thread, see bug #13065.) We define a > callback for that API, and I suspect that callback is run in the > context of that additional thread. I don't know if the API you are > using is different in this regard, but I prefer not to risk that, if > we can avoid that risk. Even if the callback is called in another thread (though I don't think there is a particular reason to do so), that is indistinguishable for Fcons from the call in the same thread if memory is properly synchronized before the call among different processors/cores. If not properly synchronized, use of other data structures such as a simple linked list does not solve the problem either (you can't even count the number of monitors without explicit synchronization by mutex). >> > And actually, I don't see why you need the list of monitor HMONITOR >> > handles, you get them from MonitorFromWindow anyway. All you need is >> > the count of the monitors, and then you can create the vector in >> > monitor_frames by simply inserting every monitor you get from >> > MonitorFromWindow, and leave the rest at nil. Or am I missing >> > something? >> >> > So could we please get rid of the consing inside the callback, and >> > just count them instead? >> >> The display-monitor-function lists all the monitors regardless of the >> existence of Emacs frames in it. > I know that, but you end up with just nil in the list of frames for > those monitors that don't have frames, right? So just use the > callback to count the monitors; then you don't need to cons a list > inside the callback, you only need to increment a counter. The cells > for the monitors that don't have frames just need to be filled with > nil. How do you get HMONITOR, which is necessary for GetMonitorInfo, for a monitor in which no Emacs frames reside? >> Of course, you can decode the string if its encoding is known (I'm not >> sure how it is encoded because I'm not familiar with W32). > You want DECODE_SYSTEM. It knows about the encoding of strings in the > current session. Thanks for the info. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp