4 ms·

> the issues with user mode callbacks too. Genuine question (because I really don't know) -- how do Linux GUI frameworks work without kernel-mode callbacks? Wh

> the issues with user mode callbacks too. Genuine question (because I really don't know) -- how do Linux GUI frameworks work without kernel-mode callbacks? What do they use instead, when they need to send messages to other windows?

qb45 13y ago
X11 clients communicate with the server using Unix domain sockets or TCP sockets. Requests, responses and event notifications are exchanged as messages. Asynchronous communication is achieved using syscalls like select and poll which take a set of file descriptors (files, special files, sockets) and block the calling thread until some descriptor from this set has new data available for reading, starts accepting writes or signals an error. GUI toolkits repeatedly poll the X server descriptor, parse incoming messages and call application-defined callbacks.
- wfunction 13y ago
  > poll and select That sounds like it's basically the same thing as Windows (GetMessage or MsgWaitForMultipleObjectsEx anyone?)... only that now you don't have the ability to use SendMessage, and need to rely exclusively on PostMessage instead. Is that correct?
  - quotemstr 13y ago
    Between threads, you rely exclusively on PostMessage anyway. You can't directly call into a routine on a different thread, so SendMessage to a window owned by another thread just posts the message to a special queue that's serviced before the regular message queue, then blocks until the other thread's window procedure processes the message. In all boils down to message-passing: in Windows, the win32k is the trusted third party that mediates interactions between different window-system clients. In the X11 case, the X server and the window manager work together to do the same job. The architecture are fundamentally similar.
    - wfunction 13y ago
      Hmm... yeah, that does sound very similar. Why does Windows need kernel-to-user callbacks in the first place then? Now I'm thinking it shouldn't even be necessary at all...
      - deleted 13y ago
        [deleted]
      - quotemstr 13y ago
        You may be interested in http://mista.nu/research/mandt-win32k-slides.pdf http://mista.nu/research/mandt-win32k-slides.pdf
        wfunction 13y ago
        Thanks, I took a look at that... but it doesn't seem to quite explain what I meant. I was thinking more like, there's no need for SendMessage() to go from user->kernel->user, even when it's on the same thread. It could just do a system call to get the wndproc for the given window, then call the wndproc from user-mode directly. Wouldn't that completely avoid needing to call back into user-mode from kernel mode?
        yuhong 13y ago
        It does this already when the window is on the same thread if no window hooks are installed. When the window is on a different thread, it is GetMessage or PeekMessage on the target thread that notices the sent message and does the user-mode callback to call the window procedure.

qb45 13y ago

X11 clients communicate with the server using Unix domain sockets or TCP sockets. Requests, responses and event notifications are exchanged as messages. Asynchronous communication is achieved using syscalls like select and poll which take a set of file descriptors (files, special files, sockets) and block the calling thread until some descriptor from this set has new data available for reading, starts accepting writes or signals an error. GUI toolkits repeatedly poll the X server descriptor, parse incoming messages and call application-defined callbacks.

wfunction 13y ago
> poll and select That sounds like it's basically the same thing as Windows (GetMessage or MsgWaitForMultipleObjectsEx anyone?)... only that now you don't have the ability to use SendMessage, and need to rely exclusively on PostMessage instead. Is that correct?
- quotemstr 13y ago
  Between threads, you rely exclusively on PostMessage anyway. You can't directly call into a routine on a different thread, so SendMessage to a window owned by another thread just posts the message to a special queue that's serviced before the regular message queue, then blocks until the other thread's window procedure processes the message. In all boils down to message-passing: in Windows, the win32k is the trusted third party that mediates interactions between different window-system clients. In the X11 case, the X server and the window manager work together to do the same job. The architecture are fundamentally similar.
  - wfunction 13y ago
    Hmm... yeah, that does sound very similar. Why does Windows need kernel-to-user callbacks in the first place then? Now I'm thinking it shouldn't even be necessary at all...
    - deleted 13y ago
      [deleted]
    - quotemstr 13y ago
      You may be interested in http://mista.nu/research/mandt-win32k-slides.pdf http://mista.nu/research/mandt-win32k-slides.pdf
      - wfunction 13y ago
        Thanks, I took a look at that... but it doesn't seem to quite explain what I meant. I was thinking more like, there's no need for SendMessage() to go from user->kernel->user, even when it's on the same thread. It could just do a system call to get the wndproc for the given window, then call the wndproc from user-mode directly. Wouldn't that completely avoid needing to call back into user-mode from kernel mode?
        yuhong 13y ago
        It does this already when the window is on the same thread if no window hooks are installed. When the window is on a different thread, it is GetMessage or PeekMessage on the target thread that notices the sent message and does the user-mode callback to call the window procedure.