Antoine Pitrou <[EMAIL PROTECTED]> wrote: > > > > The best way to make people stop complaining about the GIL and start > > using > > process-based multiprogramming is to provide solid, standardized support > > for process-based multiprogramming. > > 100% agreed. I needed a portable way to know if a program was already > running (and then to send it a simple command), the only simple solution > I found was to listen on a local TCP socket and store the port number in > a file in a known location. Not very elegant IMO.
On *nix, use a unix domain socket (location in the filesystem which acts as a listening socket). On Windows, you can use cTypes, pywin32, etc., to create a global mutex and/or COM interface. Alternatively, you can write your own cross-platform registry for services, have it running on your machines all the time, and never worry again. Or one can pick a port to use on all systems and not bother with the the file listing the port, ignore domain sockets, COM interfaces, and work-alikes. In terms of IPC, the application may determine which is most usable. If one had a service distributed across multiple machines, sockets are necessary. If one only needed local access, shared memory (perhaps via a memory mapped file) would be significantly faster. In the case of multiple machines with multiple processors, one could opt for shared memory locally but sockets globally, which could complicate the interface, result in non-uniform performance for transfers, which may then necessate complicating the application in order to gain the highest throughput (I've done this previously using MPI, it can be a PITA). - Josiah _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
