I pretty much like the way a window is send/received messages and I want to reuse that for process inter-communications - I've heard of named pipes but I don't want to write to a file - it seems ugly and unintuitive for me.
So is it possible to create a window with sharable handle across multiple processes?
Window handles are shared by default, just as you can find them through FindWindow or FindWindowEx. What you want is a bit like socket communication, client-server-client transit protocol. It's just that sockets are more powerful and can be used on different machines.
You can communicate between processes by defining your own WM_* message type, and you can control "multi-to-multi" inter-process communication. But it is not practical in practice (if ugliness is not taken into account), it is not as powerful as socket, not as mature as socket's technology, more resource occupied(because of visible window).
Of course, as #IInspectable said, there is another way of message-only windows. But the window is not visible, which is not "intuitive". Getting a window handle is as "ugly" as opening a file. It's like encapsulating a message queue into an invisible window.
In addition, if the window is accidentally closed, the communication will fail.
So summary: You can use the visible window to communicate between processes according to your preferences, but this method is not practical (unless there is a special need).
Related
I'm trying to create a multithreaded opengl application with libx11 - with one separate thread per window, and one manager thread.
I have an event loop in the manager thread:
while(true)
while(XQLength(mPlatformData->display)){
XNextEvent(mPlatformData->display, &event);
std::cout << "event" << std::endl;
}
}
This is a great event loop for single threaded applications, but with this multithreaded setup strange things happen.
When I'm creating a window, I need to disable the event queue, or GLXMakeCurrent will just hang - my entire thread stops, and does nothing.
I can't find much information about multithreaded X11 applications on the net, should I handle my events differently?
It is known that Xlib has several unfixable runtime issues that manifest in concurent access situations. I'm guessing you're running into exactly one of those.
This is one among the reasons why Xcb was created in the first place: Fix the problems of Xlib. GLX is specified against Xlib so this might seem like a show stopper when it comes to OpenGL. However there is a Xlib wrapping around Xcb and one can safely use that to interface with GLX and still use Xcb for the rest of the program: http://xcb.freedesktop.org/opengl/
I see two possible solutions:
Put a XLockDisplay/Mutex around XNextEvent and the GLX calls each; you don't have to lock for ordinary OpenGL, just the functions prefixed glX....
Use Xcb to get runtime correct behaviour and follow the guide I linked above to make it work with OpenGL/GLX.
As eile said you should check that you use XInitThreads.
I was able to get some good results from it when i used a background thread to do the window drawings of an animation. There seems to be no real problem if you stick to drawing code.
If you need more then that and because you are using low level libX11 the best is just to open multiple X11 connections and use one connection per toplevel window. I did this 10 years ago when i played with developing a BeOS cross platform toolkit and when everything was in a worse state then it is now.
You can use this even for event handling and child windows of a toplevel. But this needs some very tricky code for the XEvent masks.
What are you doing in your render threads? In any case, if you share a Display* connection across different threads you have to call XInitThreads.
I've made good experiences with one Display connection per thread. Use XSelectInput to get events on your main thread. Window IDs are shareable across different Display* connections.
Using the lisp implementation of the X11 protocol, get-overlay-window freezes when no compositor is running. If I kill the lisp process, the xid is printed out.
This also freezes my lisp window manager running in another lisp thread, though same process. Basically X acts like it's been grabbed, so thank god for ctrl-alt-f1.
Some previous questions about composite show others running into similar problems when no compositor is running.
I'm guessing that maybe the server is waiting for some sort of out of protocol authorization or something? Or something particular sequence of events has to be completed?
Having access to the overlay window when another compositor is active isn't helpful for writing a compositor!
Apparently I had a reading comprehension fail with the protocol description, or they a writing fail.
Asking composite to redirect windows automatically ensures the windows contents get drawn. It does not ensure they get drawn to the overlay! Nor does the overlay appear to be transparent. So even with setting all windows to be automatically updated, when the overlay window gets mapped by the call to get its XID it blocks you from seeing any other updates to the screen and blocks all input.
Making the overlay in a sense not very useful. Or the request to have automatic updates for redirected windows not useful. Either way, seems will have to paint every single pixel even of the windows we're not interested in.
Maybe it's just a driver thing?
I was trying to work with Named Pipe as a communication channel between injected stubs in various processes.
I was reading and it states
Process Isolation
Sandboxing the application kernel objects, the AppContainer environment prevents the application from influencing, or being influenced by, other application processes. This prevents a properly contained application from corrupting other processes in the event of an exception.
It also states here that
Windows 10, version 1709: Pipes are only supported within an app-container; ie, from one UWP process to another UWP process that's part of the same app. Also, named pipes must use the syntax "\.\pipe\LOCAL\" for the pipe name.
Does this mean I can no longer access kernel objects from NtFsControlFile (FSCTL_PIPE_LISTEN, FSCTL_PIPE_WAIT, FSCTL_PIPE_DISCONNECT) to communicate with pipes in other processes than my own App Container? Or is it simply saying that the semantics of this operation changed?
My question is, does this change implicate an actual problem, or can I still use one named pipe from one process to talk with another; but it's not advised to do so?
Are there any restrictions to the types of I/O kernel objects that one can use for redirection when calling CreateProcess()?
As can be seen in the documentation, one of the parameters the function receives is the STARTUPINFO structure. Within this structure, one can specify handles for both input, output and errors. However, it's not mentioned what specific kinds of I/O kernel objects can be use.
I have tested the use of windows sockets as I/O devices, and found that it works. However, I assume that the nature of such a device is rather different than a file object, which makes me wonder if it was actually intended that sockets can be used for this purpose.
When using STARTF_USESTDHANDLES to specify STDIN/OUT/ERR handles for CreateProcess(), they are supposed to be valid kernel objects that are compatible with CloseHandle() (since that is stated as much in the STARTUPINFO documentation). Sockets are not kernel objects and do not meet the CloseHandle() requirement (although sockets can be used with the ReadFile() and WriteFile() kernel functions).
When a caller is launching a redirected process on behalf of a socket connection, the typical scenario is for the caller to use an anonymous pipe via CreatePipe() for the redirection and then proxy data between the socket connection and the pipe as needed.
That being said, one of the answers to another question states that is possible to use a socket for redirection, but only if the socket was created using WSASocket() with the WSA_FLAG_OVERLAPPED flag omitted, since redirection does not allow overlapped handles to be used. I have not personally attempted that solution myself, so I do not know I it works or not. It is better to be safe and use a pipe instead, especially if you have no control over (or knowledge of) how the socket was created.
Well, not sure if I'm answering your question, but in terms of inheritance, as of MSDN documentation states, one can modify the inheritance policy of a socket by means of SetHandleInformation(). This way you can prevent child processes from inherit a listening socket of the parent process.
I don't believe this is documented.
However, common practice says that the standard I/O handles may be any such stream devices as TCP/IP sockets, COM or LPT ports, files, pipes, and so on. I believe there is sample code on MSDN for several of these scenarios.
(The default standard I/O handles are to the console, not to a file, so we can safely assume at least that they do not have to be file handles!)
I am writing a cross-platform library which emulates sockets behaviour, having additional functionality in the between (App->mylib->sockets).
I want it to be the most transparent possible for the programmer, so primitives like select and poll must work accordingly with this lib.
The problem is when data becomes available (for instance) in the real socket, it will have to go through a lot of processing, so if select points to the real socket fd, app will be blocked a lot of time. I want the select/poll to unblock only when data is ready to be consumed (after my lib has done all the processing).
So I came across this eventfd which allows me to do exactly what I want, i.e. to manipule select/poll behaviour on a given fd.
Since I am much more familiarized with Linux environment, I don't know what is the windows equivalent of eventfd. Tried to search but got no luck.
Note:
Other approach would be to use another socket connected with the interface, but that seems to be so much overhead. To make a system call with all data just because windows doesn't have (appears so) this functionality.
Or I could just implement my own select, reinventing the wheel. =/
There is none. eventfd is a Linux-specific feature -- it's not even available on other UNIXy operating systems, such as BSD and Mac OS X.
Yes, but it's ridiculous. You can make a Layered Service Provider (globally installed...) that fiddles with the system's network stack. You get to implement all the WinSock2 functions yourself, and forward most of them to the underlying TCP. This is often used by firewalls or antivirus programs to insert themselves into the stack and see what's going on.
In your case, you'd want to use an ioctl to turn on "special" behaviour for your application. Whenever the app tries to create a socket, it gets forwarded to your function, which in turn opens a real TCP socket (say). Instead of returning that HANDLE though, you use a WinSock function to create ask for a dummy handle from the kernel, and give that to the application instead. You do your stuff in a thread. Then, when the app calls WinSock functions on the dummy handle, they end up in your implementation of read, select, etc. You can decouple select notifications on the dummy handle from those on the actual handle. This lets you do things like, for example, transparently give an app a socket that wraps data each way in encryption, indistinguishably from the original socket. (Almost indistinguishably! You can call some LSP APIs on a handle to find out if there's actually and underlying handle you weren't given.)
Pretty heavy-weight, and monstrous in some ways. But, it's there... Hope that's a useful overview.