[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: sysdeps/mach/hurd/profil.c (was: [PATCH] hurd: align -p and -pg beha
From: |
Samuel Thibault |
Subject: |
Re: sysdeps/mach/hurd/profil.c (was: [PATCH] hurd: align -p and -pg behavior on Linux) |
Date: |
Thu, 25 Feb 2016 15:23:13 +0100 |
User-agent: |
Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30) |
Thomas Schwinge, on Thu 25 Feb 2016 15:05:21 +0100, wrote:
> Should we move the initialization of profil_reply_port elsewhere, or be
> prepared for profil_reply_port to be MACH_PORT_NULL in
> sysdeps/mach/hurd/profil.c:fetch_samples (by returning early?), or not
> call fetch_samples from sysdeps/mach/hurd/profil.c:__profil if
> profil_reply_port is MACH_PORT_NULL, or make sure that we're always
> properly initialized by making sure that the profile thread is always
> scheduled to execute right after it's been created?
__profil calls __thread_suspend (profile_thread); then uses
fetch_samples. It seems unsafe to me to be using the profile thread's
reply port for the last profil_task_get_sampled_pcs call: who knows
where the thread got suspended?
> These days, do we still need the threadvar-avoidance magic, the "special
> RPC stubs", and the "special_profil_failure"?
With TLS support, I'd say we don't, which gets the profil_reply_port
issue away.
> As there are accesses to variables shared between different threads,
> should these be re-written to use GCC's atomic/sync load/store builtins
> with appropriate semantics?
The current way seems unsafe at least between update_waiter and
fetch_samples, indeed. I'd say just go with a libc_lock.
Samuel