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

[YAMAMOTO Mitsuharu]

>>>>> 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
                                address@hidden