Change in vdsm[master]: lib: allow to set system thread names

fromani at redhat.com fromani at redhat.com
Tue May 19 07:04:06 UTC 2015


Francesco Romani has posted comments on this change.

Change subject: lib: allow to set system thread names
......................................................................


Patch Set 3:

(3 comments)

https://gerrit.ovirt.org/#/c/41052/3/lib/vdsm/threadname.py
File lib/vdsm/threadname.py:

Line 40:         'pthread_setname_np unavailable. '
Line 41:         'System thread names will not be set.')
Line 42: 
Line 43: 
Line 44: def systemname(name):
> Even better name - setname()
OK, since this is non-portable, I'm fine to use 'pthread.py'.
I'm a bit worried about the possible naming clash between  pthread.py and pthreading.py.

I don't think we should bind together python name and system name. The drawbacks IMO overweight the benefits because system name is 15 bytes long at maximum, while python name can be anty python string.

If we bind the two together we must conform to the stricter one, hence only 15 bytes
Line 45:     """
Line 46:     Allows to set a system-wide thread name.
Line 47:     This decorator should be used on `func' callables which implement
Line 48:     a threading.Thread target.


Line 66:     16 character maximum, including the '\0' terminator.
Line 67:     http://man7.org/linux/man-pages/man3/pthread_setname_np.3.html
Line 68:     """
Line 69:     if len(name) > 15:
Line 70:         raise ValueError("System thread name too long")
> I think we can inline this into the decorator, and we don't need so much de
Will change.


https://gerrit.ovirt.org/#/c/41052/3/vdsm.spec.in
File vdsm.spec.in:

Line 1333: %{python_sitelib}/%{vdsm_name}/response.py*
Line 1334: %{python_sitelib}/%{vdsm_name}/netconfpersistence.py*
Line 1335: %{python_sitelib}/%{vdsm_name}/schedule.py*
Line 1336: %{python_sitelib}/%{vdsm_name}/sslutils.py*
Line 1337: %{python_sitelib}/%{vdsm_name}/threadname.py*
> The best name for this module is pthread.py, and the function/decorator pth
I just don't know what are the future plans for pthreading. Will we drop that once we move on python3?

Moreover, I'd like to have this change as easy as backport to 3.5 as possible, because is 3.5 the one which benefits the most of this patch. Move this change to pthreading will make things easier or harder on this regard?
Line 1338: %{python_sitelib}/%{vdsm_name}/sysctl.py*
Line 1339: %{python_sitelib}/%{vdsm_name}/udevadm.py*
Line 1340: %{python_sitelib}/%{vdsm_name}/utils.py*
Line 1341: %{python_sitelib}/%{vdsm_name}/vdscli.py*


-- 
To view, visit https://gerrit.ovirt.org/41052
To unsubscribe, visit https://gerrit.ovirt.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: Ib96bd0471a07449d2a0a0328137e8437aefad901
Gerrit-PatchSet: 3
Gerrit-Project: vdsm
Gerrit-Branch: master
Gerrit-Owner: Francesco Romani <fromani at redhat.com>
Gerrit-Reviewer: Dan Kenigsberg <danken at redhat.com>
Gerrit-Reviewer: Federico Simoncelli <fsimonce at redhat.com>
Gerrit-Reviewer: Francesco Romani <fromani at redhat.com>
Gerrit-Reviewer: Jenkins CI
Gerrit-Reviewer: Nir Soffer <nsoffer at redhat.com>
Gerrit-Reviewer: Yaniv Bronhaim <ybronhei at redhat.com>
Gerrit-Reviewer: automation at ovirt.org
Gerrit-HasComments: Yes


More information about the vdsm-patches mailing list