This is the mail archive of the cygwin-patches mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi Jon, On Mon, 22 Feb 2016, Jon Turney wrote:
Thanks for this. A few comments inline. On 20/02/2016 08:16, Mark Geisert wrote:+/* Called from profil.c to sample all non-main thread PC values for profiling */+extern "C" void +cygheap_profthr_all (void (*profthr_byhandle) (HANDLE)) +{ + for (uint32_t ix = 0; ix < nthreads; ix++) + { + _cygtls *tls = cygheap->threadlist[ix].thread; + if (tls->tid) + profthr_byhandle (tls->tid->win32_obj_id); + } +}There doesn't seem to be anything specific to profiling about this, so it could be written in a more generic way, as "call a callback function for each thread".
I saw your later conversation with Corinna on the list re why cygwin_internal() is involved now. (I too had stumbled over the cygwin1.dll/libgmon.a gap when I started this work.) Given the necessity of the separation, does it still make sense to write a generic per-thread callback mechanism and then make use of it for this patch, or is that overkill? I can't tell.
+ if ((prefix = getenv("GMON_OUT_PREFIX")) != NULL) {setup-env.xml might be an appropriate place to mention this environment variable.
I am now writing a gprof.xml that will be tied into the existing programming.xml. I plan to document GMON_OUT_PREFIX in gprof.xml. Do you think that's sufficient?
..mark
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |