On Sun, Mar 9, 2008 at 11:52 AM, Gilad Ben-Yossef <[EMAIL PROTECTED]> wrote:
> Jamie Lokier wrote:
> > Gilad Ben-Yossef wrote:
> >> Glauber Costa wrote:
> >>> This patch introduces a "thread_id" variable to CPUState.
> >>> It's duty will be to hold the process, or more generally, thread
> >>>
M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Jamie Lokier <[EMAIL PROTECTED]> writes:
> : Btw, unfortunately pthread_self() is not safe to call from signal
> : handlers.
>
> And also often times meaningless, as signal handlers can run in
> arbitrary threads...
That's usua
In message: <[EMAIL PROTECTED]>
Gilad Ben-Yossef <[EMAIL PROTECTED]> writes:
: > What you're supposed to do with pthreads in general is use pthread_self().
:
: Unfortunately, AFAIK the opaque handle that pthread_self() returns is
: not quite meaningless outside of the process whereas
In message: <[EMAIL PROTECTED]>
Jamie Lokier <[EMAIL PROTECTED]> writes:
: Btw, unfortunately pthread_self() is not safe to call from signal
: handlers.
And also often times meaningless, as signal handlers can run in
arbitrary threads...
Warner
Jamie Lokier wrote:
Gilad Ben-Yossef wrote:
Glauber Costa wrote:
This patch introduces a "thread_id" variable to CPUState.
It's duty will be to hold the process, or more generally, thread
id of the current executing cpu
env->nb_watchpoints = 0;
+#ifdef __WIN32
+env->thread_id = GetCurr
Gilad Ben-Yossef wrote:
> Glauber Costa wrote:
> >This patch introduces a "thread_id" variable to CPUState.
> >It's duty will be to hold the process, or more generally, thread
> >id of the current executing cpu
> >
> > env->nb_watchpoints = 0;
> >+#ifdef __WIN32
> >+env->thread_id = GetCurr
Glauber Costa wrote:
This patch introduces a "thread_id" variable to CPUState.
It's duty will be to hold the process, or more generally, thread
id of the current executing cpu
env->nb_watchpoints = 0;
+#ifdef __WIN32
+env->thread_id = GetCurrentProcessId();
+#else
+env->thread_id =
