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
