[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: x-display-pixel-width/height inconsistency

From: YAMAMOTO Mitsuharu
Subject: Re: x-display-pixel-width/height inconsistency
Date: Fri, 10 May 2013 16:47:36 +0900
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)

>>>>> On Fri, 10 May 2013 10:06:18 +0300, Eli Zaretskii <address@hidden> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]