On Tue, 2009-12-08 at 18:25 -0500, Steve Huston wrote:
> 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:

It's not using the pid that is a problem per se it's using the type
pid_t. So if you are using a DWORD type coming from
GetCurrentProcessId() then this is not an issue.

Also using pid_t in purely posix code isn't an issue as the windows code
never sees it. The issue is using pid_t in the platform independent
code.

> 
> - print it to cout (Windows, posix)
> - use it to open a handle to the broker process (Windows)

Ah yes, I see that now - it looks like it would be encapsulatable though
or replaced with another event, as it's being used not for signalling
but to detect process exit.

> 
> > 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.

As above actually not for the signalling itself though.

> 
> > 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?

Probably easier, but not necessarily better! I'll fiddle around a bit
and see if I can get something simple enough.

Andrew


> 
> -Steve
> 



---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Reply via email to