many programs, especially GUI apps, when a 2nd one is started, tell the 1st one to open the window and the 2nd on exits. i am looking for a suggested code pattern for this kind of communication setup where the process that is the 2nd instance of an executable can find and set up brief communications with the 1st instance of the same executable. in particular, i am curious how to avoid finding a process of a different executable that is also being interpreted by python. in a typical GUI case, this communication would send what X display the 2nd instance was started on and any specified parameters to the 1st instance.
this is not a case of existing code that fails because things have not reached that level yet, so there is no (failing) code to show. i am still thinking through many potential projects and looking for a pattern for this.
Sockets? Usually, they are used for interprocess comunication
(Sep-07-2017, 02:54 AM)wavic Wrote: [ -> ]Sockets? Usually, they are used for interprocess comunication
that's what i was initially thinking of doing. but that would mean the 1st process is perpetually listening on some port. i don't see that happening. and i don't see a unix named socket in the file space, either.
If you know the pid of the other process, you could use a signal. The original process would set a signal handler, then anything that sent that signal, would trigger the event to fire off (in this case, opening a new browser window). That's a little more lightweight than using sockets.
https://docs.python.org/3/library/signal.html
Quote:That's a little more lightweight than using sockets.
It should be. Event-driven application uses less resources
(Sep-26-2017, 08:14 PM)nilamo Wrote: [ -> ]If you know the pid of the other process, you could use a signal. The original process would set a signal handler, then anything that sent that signal, would trigger the event to fire off (in this case, opening a new browser window). That's a little more lightweight than using sockets.
https://docs.python.org/3/library/signal.html
sure, you can send a signal, but that's just an event. it would have nice to have had, from the beginning, a means to send a block of data from one process to another. it would be like a datagram where process id == port number, and the listener can only listen on that, and fds can be passed along. that would allow real communication. the receiving process gets the process id of the sender, its {e,r}{g,u}id, ppid, and other info along with up to 4k of data and up to 4 fds. if that had been in the unix design, lots of things would be so much easier. but maybe named sockets can be adapted to this.
Well, asyncio is capable to wait for a connection and once a such is established a could be used for this purpose. It will not be high CPU load as using while loop.
I forgot to mention that the built-in asyncio Protocols or Transport must be used since there are not blockable.
the big issue for me is finding the other process running the same python code, and being sure the match does not get it wrong by matching "python" to "python" in the process argv[0] string, which a C program might naȉvely do.
Maybe a message queue can help. I've used sometimes
http://zeromq.org/bindings:python over network. But you can use this also across processes on the same machine and in the same process. There are different patterns. Asyncio is also supported.