Hello.


24 jul 2012 kl. 01:26 skrev Stefan Monnier <monnier@IRO....>:

>>>> This is a known issue, partly to do with how the event loop is
>>>> implemented.  A smarter loop doubles the speed, but it is still slower
>>>> than say X.
>>> Does this issue have a bug number?  Any discussions on fixes that are
>>> relevant?  A simple way to illustrate the problem?
>> See 7761.
>
> This bug number does not seem to discuss much this event-loop problem.
> Is there some place where this problem is discussed?

It has a way to see the problem. Ian not aware of any event loop discussion, it is something I saw when investigating that bug.

> I hope someone can try and tackle it, e.g. starting by comparing the
> approach used currently in the NS port compared to the X, Gtk, Windows
> or Mac ports, so as to devise a plan.

I have a plan to do more or less what Gdk does on OSX, use lower level (Core Foundation) API:s. The NS-port has many special things (resizing, redrawing and more) that depends on how things are done now, so it isn't just a replacement of a few functions.

I haven't looked at the Mac port, but if it uses CF for the event loop, code may be reused from there.

The basic concept is to have one thread for file descriptors and let the main thread deal with Cocoa events.  The code today does something similar, but it relies on polling each 0.1 second.

    Jan D.