| To: | "Ken McDonell" <kenj@xxxxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: pmRegisterDerived return values |
| From: | fche@xxxxxxxxxx (Frank Ch. Eigler) |
| Date: | Sat, 23 Jan 2016 16:02:26 -0500 |
| Cc: | "'Nathan Scott'" <nathans@xxxxxxxxxx>, "'Marko Myllynen'" <myllynen@xxxxxxxxxx>, pcp@xxxxxxxxxxx |
| Delivered-to: | pcp@xxxxxxxxxxx |
| In-reply-to: | <007401d155a4$fd1e1660$f75a4320$@internode.on.net> (Ken McDonell's message of "Sat, 23 Jan 2016 17:12:06 +1100") |
| References: | <569CB025.4070603@xxxxxxxxxx> <569CB7C5.7030803@xxxxxxxxxxxxxxxx> <1305297915.11201184.1453261568406.JavaMail.zimbra@xxxxxxxxxx> <007401d155a4$fd1e1660$f75a4320$@internode.on.net> |
| User-agent: | Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) |
kenj wrote: > Can anyone explain why there are > 1 threads in play here? There is > nothing explicit in bad.py that suggests it will be executed using > multiple threads. Yes, that's a good question. > [...] The problem for us is that if Python code with no obvious > multi-threading ends up calling into libpcp with different pthread > execution contexts at different times during its execution we're > going to have a problem ... thread-private data for one, and > single-threaded guards in libpcp for another. For example, check out the python bindings in python/pcp/pmapi.py for a function like pmLookupName. Before the desired C PMAPI call, it does a pmUseContext. If the python VM were free to execute pieces of that python function with different threads, the pmUseContext would not work. - FChE |
| Previous by Date: | pcp_3.10.9_amd64.changes REJECTED, Chris Lamb |
|---|---|
| Next by Date: | Re: pmRegisterDerived return values, Frank Ch. Eigler |
| Previous by Thread: | RE: [pcp] pmRegisterDerived return values, Ken McDonell |
| Next by Thread: | Re: [pcp] pmRegisterDerived return values, Nathan Scott |
| Indexes: | [Date] [Thread] [Top] [All Lists] |