bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows

[martin rudalics]

> I don't see a need for giving an example for something that is so
> blatantly wrong: it calls one thread's code from within another.
> Since the Emacs input thread was written _specifically_ to overcome
> problems with delivering input asynchronously, it should be clear to
> anyone that mixing such threads is dead wrong, period.

I can only _speculate_ on how Emacs is supposed to handle a frame size
change requested by a Lisp routine.

(1) Calculate (and internally store) the new size and send the WM
    (window manager) an appropriate request.

(2) Continue the calling routine with the size calculated in (1).

(3) When the WM confirmation finally arrives treat it as a resize
    request initiated by the WM.

The idea seems that the sizes calculated in (1) and the size request in
(3) coincide and no further resizing is necessary thereafter.

Apparently Jason changed (1) on Windows in the sense that it does not
internally store the new size.  So if a Lisp routine issues another
resize request before (3) is handled, (1) starts calculations with the
values as they were before the Lisp routine started.  The request that
eventually gets processed by the Windows WM is the last
resize/positioning request issued by the Lisp routine, with the values
valid before the Lisp routine started.

Now grischka's proposal seems to wait for the WM's confirmation within
(1), that is embed (3) in (1), and have (2) proceed with the values
promised (or confirmed) by the WM.  This apparently runs counter to the
ideology that the processing of asynchronous input should not happen in
certain occasions and apparently a step like (1) is one of these.

So the first thing we'd have to agree upon is whether we want a function
like `set-frame-height' process messages of the WM.  If we don't want
that, we have to find another way to make `set-frame-height' DTRT which
seems non-trivial to me.

If we want that, we have to decide how to synchronize the handling of a
confirmation message with the rest of system messages arriving around
that time.  For this purpose, we have to determine what can be safely
processed and what must be processed to ensure liveness while waiting
for the confirmation.  (I suppose that's what Jason's "inter-thread
synchronization" amounts to, though I don't understand the term "thread"
in the present context - sorry.  But maybe that's what ATTACH_THREADS
was about.)

Till we agree on something here I can test grischka's patches to know
whether his approach can handle the problem at all - that is whether the
confirmation gets through and is handled.

martin