[Top][All Lists]

[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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]