Hi Andrew, > I'm looking at QPID-1951: > > Eliminating ssize_t is trivial.
Ok. > pid_t is used in a few more places though. However it is only used in > connection with LockFile. Either internally in Lockfile or to > communicate a pid out of LockFile so that the process can be > signalled. The other things the pid is used for are: - print it to cout (Windows, posix) - use it to open a handle to the broker process (Windows) > It seems to me that the entire LockFile class could be better factored > to eliminate passing non portable process ids around by delegating > signalling the other process to the LockFile class itself. I would > change the name to something else at that point > (suggestions?). In that > case the lockfile itself becomes just an internal part of the > signalling > mechanism. > > Following in that direction it looks to me like for Windows at least > doing this allows you to entirely replace the lock file > itself with the named event that is already being used. No, the pid is still needed to get a handle to the process that's being signalled. > Steve, Alan (as you are both mostly responsible for these > implementations) is there anything I'm missing here or is this a good > direction? It seems the pid is still needed; maybe using a qpid::pid_t type would be easier? -Steve --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
