Re: pcp updates: libpcp connection unsharing

Hi, Mark -


> >     github issues/118: stop sharing sockets to same pmcd
> > [...]
> I'm unsure whether to merge this one. On the one hand it should squash
> numerous bugs involving locking and connection sharing and simplify the
> code (which sounds good), but on the other hand, how close are we to
> understanding those bugs 

I don't know how to measure that.  There exists at least one current
buggy area, which has been reworked by kenj & others in recent months
and still has problems.  So "we don't know" is probably accurate.

> and what functionality do we lose? 

I believe "none".

> and what are the performance or resource (maxfds?) implications?

Naturally, one FD per pmcd connection.  PCP applications that have
thousands of concurrent connections are limited to ...  almost none?
Only pmmgr/pmwebd qualify, and neither crashes on failing connections.

There may be negative testability implications, in that pmcd would
have to retain code for incoming multiplexed connections, but the
mainstream code would no longer create them, so only old (or fake)
clients would stress that part of pmcd.  (We should probably have
somewhere a suite of such old binaries to try for intercompatibility
with newer servers anyway.)

There may be positive performance implications, e.g., should there be
code in libpcp that works to demultiplex the shared connections, or
should pmcd ever become more concurrent.


> Do we need the c_pmcd refcnt/mutex followup patch too?

Not "need" in the sense of something being broken now, but would be a
good followup cleanup to save some time/space.  Some downside is that
the c_pmcd structure may be exposed in the pcp abi (since it's in a
public header, and may be reachable from functions exported from
shared libraries), so could be strictly speaking an ABI break.


> Frank, the patch itself seems superficially OK, except for this bit:
>     if (1 /* new->c_pmcd == NULL*/) {
> which should be easily cleaned up.

I left that there as an assert/documentation in disguise.  We can
certainly remove that (and the level of nesting in the block).


- FChE

-=-=-=-=-=-=-=-=-=-=-=-
pcp mailing list
[email protected]
https://groups.io/g/pcp/messages
-=-=-
Groups.io Links:

You receive all messages sent to this group.

View/Reply Online (#14651): https://groups.io/g/pcp/message/14651
View All Messages In Topic (3): https://groups.io/g/pcp/topic/3038481
Mute This Topic: https://groups.io/mt/3038481?uid=174580
New Topic: https://groups.io/g/pcp/post

Change Your Subscription: https://groups.io/g/pcp/editsub?uid=174580

Group Home: https://groups.io/g/pcp
Contact Group Owner: [email protected]

Terms of Service: https://groups.io/static/tos

Unsubscribe: https://groups.io/g/pcp/leave/354243/563757577/xyzzy
-=-=-=-=-=-=-=-=-=-=-=-