pcp
[Top] [All Lists]

libpcp vs. multithreading: pmns round

To: pcp developers <pcp@xxxxxxxxxxx>
Subject: libpcp vs. multithreading: pmns round
From: "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Date: Sun, 1 Mar 2015 10:16:37 -0500
Delivered-to: pcp@xxxxxxxxxxx
User-agent: Mutt/1.4.2.2i
Hi -

While testing pmwebd/webapp changes recently, I tried out the
multithreaded mode again.  You might recall that this had to be made
default-off because libpcp is not actually multithread-safe [1] [2],
and that remains the status quo.

I'd like some advice as to how to improve the PMNS problems, which
appears to be the next target for some surgical fixing.  The problem
here is that the libpcp/src/pmns.c globals curr_pmns (and to a lesser
extent main_pmns) represent shared resources without proper
lifetime/concurrency management (token PM_LOCK's don't cut it).  A
trivial failure scenario is two threads opening one separate archive
each; one of them closes its context, thus freeing curr_pmns; the next
one goes boom at the next pmLookupName.

A few possibilities:
- making curr_pmns a per-thread global (a peer to __pmTPD.curcontext)
- putting the pmns pointers right into the __pmContext impl.h structure
  to make it per-context rather than global
  In the latter case, for archives, it'd just link to the ac_log->l_pmns,
  and for other cases it'd link to a global read-only pmns.  
Which of these (or something else) looks better?

[1] http://oss.sgi.com/bugzilla/show_bug.cgi?id=1055
[2] valgrind --tool=helgrind pmwebd -M8 ....

- FChE

<Prev in Thread] Current Thread [Next in Thread>