Re: pcp updates: libpcp locking and concurrency control changes

Hi, Ken -

> [...]
>> exit() probably doesn't need any /* THREADSAFE */ marking; it's pretty
>> safe all right.  (We shouldn't call it much or at all from within the
>> library, really.)
>
> The THREADSAFE marking is really for the ../doc/find-unsafe script
> ... it means I've looked at this one, and determined that the use is
> threadsafe ... as you say the (a) any race on exit status really is
> not an issue

Or more alternately, we can consider exit() as .safe rather than
.unsafe, but ...

> (b) we should avoid exit() as much as possible ... I believe we really
> only go down an exit error path when all is lost, e.g. realloc() fails
> (or more generally OOM conditions), or when the PCP installation is
> borked, e.g. /etc/pcp.conf is missing, or some other world-ending
> scenario.

These might be world-ending conditions from the point of view of
particular pcp client -applications- we ship, not from libpcp per se,
and definitely not for other larger applications for whom libpcp is
peripheral.  libpcp should return error codes and let the apps decide.
(See also RHBZ1187588 / commit 616acd0d74.)


> [...]
> 	Pamela the Punter is a PMAPI developer who wants to build a
> multi-threaded application that calls some POSIX unsafe routines
> outside the PMAPI use, e.g. getservbyport().  We can document, and
> Pamela can use a template like:
> 	PM_LOCK(__pmLock_extcall);
> 	getservbyport() code
> 	PM_UNLOCK(__pmLock_extcall);
>
> This will work as long as everytime we call an external routine
> outside libpcp that is not thread safe we acquire (and later release)
> the __pmLock_extcall mutex.  And if Pamela does the same, we're all
> happy and safe.
> [...]

That seems really unfortunate - to enshrine libc locking artifacts in
libpcp abi + api.  I can't think of any precedent in other libraries.

How about this alternative: we autoconf libpcp for the presence of all
the various thread-safe libc/posix FOO_r functions we really require.
If they're there, we use (only) them, and thus no _extlock.  If they're
not there, we configure libpcp as single-threaded, so again no _extlock.
Any idea how many of our platforms would be affected?


- FChE

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links:

You receive all messages sent to this group.

View/Reply Online (#14979): https://groups.io/g/pcp/message/14979
View All Messages In Topic (4): https://groups.io/g/pcp/topic/4185439
Mute This Topic: https://groups.io/mt/4185439?uid=174580
New Topic: https://groups.io/g/pcp/post
-=-=-
pcp mailing list
[email protected]
https://groups.io/g/pcp/messages
-=-=-
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
-=-=-=-=-=-=-=-=-=-=-=-