You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Andrew Stitcher <as...@redhat.com> on 2009/12/08 21:35:43 UTC
C++ broker: LockFile and shutdown (eliminating pid_t)
I'm looking at QPID-1951:
Eliminating ssize_t is trivial.
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.
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.
Steve, Alan (as you are both mostly responsible for these
implementations) is there anything I'm missing here or is this a good
direction?
Andrew
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: C++ broker: LockFile and shutdown (eliminating pid_t)
Posted by Alan Conway <ac...@redhat.com>.
On 12/08/2009 03:35 PM, Andrew Stitcher wrote:
> I'm looking at QPID-1951:
>
> Eliminating ssize_t is trivial.
>
> 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.
>
> 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.
>
> Steve, Alan (as you are both mostly responsible for these
> implementations) is there anything I'm missing here or is this a good
> direction?
>
That sounds like the way to go to me.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: C++ broker: LockFile and shutdown (eliminating pid_t)
Posted by Andrew Stitcher <as...@redhat.com>.
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-subscribe@qpid.apache.org
RE: C++ broker: LockFile and shutdown (eliminating pid_t)
Posted by Steve Huston <sh...@riverace.com>.
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-subscribe@qpid.apache.org