<div dir="ltr">I didn't test it extensively, but the updated sources+build seem to be working. Thanks~<br><br><div class="gmail_quote">On Fri, Jul 25, 2008 at 3:46 PM, Gary Byers <span dir="ltr"><<a href="mailto:gb@clozure.com">gb@clozure.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">My mistake: if you just do:<br>
<br>
? (make-process "foo")<br>
<br>
the process will run a little bit of code, add itself to the list of<br>
all processes, then signal a semaphore and wait to be preset and<br>
enabled.<br>
<br>
In David's case, the creating thread's wait had timed out, but by the<br>
time he did :proc, interrupted the waiting thread, and printed a<br>
backtrace, the thread was initialized and ready to go, and its<br>
whostate was "Active". That's a change in how whostates are<br>
implemented; in 1.1, the newly-reset thread would have reported itself<br>
as "Reset" instead of "Active", and the former's more accurate. The<br>
thread isn't really "Active" - it's still waiting to be preset and<br>
enabled - and I started postulating that the thread had somehow been<br>
enabled due to very low-level wires getting crossed somewhere.<br>
<br>
So, there are two bugs here:<br>
<br>
1) the whole idea of a timeout in PROCESS-ENABLE is wrong (since we<br>
don't generally know how long it'll take for the target thread to<br>
get ready to run), and we should just wait indefinitely.<br>
<br>
2) a newly-created or newly-reset thread should not have a whostate of<br>
"Active"; that's an unintentional change which can cause at least one<br>
person (the person who made the change) to get very confused.<br>
<br>
Sorry; will fix.<div><div></div><div class="Wj3C7c"><br>
<br>
<br>
<br>
<br>
On Fri, 25 Jul 2008, David Rager wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In the case described, when I (:y 35), and type :go (or whatever made the<br>
lisp system ignore the warning), IIRC, it all worked. Therrefore, IIRC,<br>
it's probably the latter, where one second isn't enough (or something new is<br>
occurring to make threads not swap in as much).<br>
<br>
The thing that may be indicative that it's not an OS problem, is that this<br>
just started happening when I upgraded to the RC verson of CCL (RC 1.2?). I<br>
can inquire of our IT department if you would find whether there was an OS<br>
change during this period to be relevant information. RC 1.2 fixed another<br>
OpenMCL problem (which I was quite pleased about), so it wasn't like I could<br>
just keep using the old OpenMCL.<br>
<br>
At least now our group is no longer the only group seeing and reporting this<br>
behavior.<br>
<br>
On Fri, Jul 25, 2008 at 1:25 PM, Gary Byers <<a href="mailto:gb@clozure.com" target="_blank">gb@clozure.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In the original bug report, the backtrace for what was thread #35 showed<br>
<br>
(2AAAAD619B18) : 0 (PROCESS-ENABLE #<PROCESS Worker thread(38) [Active]<br>
#x300043A1C8ED> [...]) 405<br>
(2AAAAD619B68) : 1 (%PROCESS-RUN-FUNCTION '(:NAME "Worker thread")<br>
#<COMPILED-LEXICAL-CLOSURE (:INTERNAL ACL2::RUN-THREAD) #x300043A1CD7F> NIL)<br>
1373<br>
(2AAAAD619C58) : 2 (PROCESS-RUN-FUNCTION "Worker thread"<br>
#<COMPILED-LEXICAL-CLOSURE (:INTERNAL ACL2::RUN-THREAD) #x300043A1CD7F><br>
[...]) 213<br>
<br>
and :proc showed<br>
<br>
38 : Worker thread [Active]<br>
35 : Worker thread [semaphore wait] (Requesting terminal input)<br>
14 : Worker thread [semaphore wait]<br>
1 : -> listener [Active]<br>
0 : Initial [Active]<br>
<br>
In other words, thread 35 created thread 38 and was waiting for it<br>
to signal a semaphore that would indicate that it's reset itself<br>
and is ready to be enabled (given a function to run). :PROC shows<br>
that thread 38 is already running, which doesn't make much sense.<br>
The Linux kernel that David Rager was running was one that allegedly<br>
had just fixed a bug which could cause the the wrong thread to be<br>
awakened via FUTEX_WAIT, and it seemed plausible that that bug hadn't<br>
really been fixed there. The case that failed reliably for David<br>
on the machine that David was using worked reliably for me, similar<br>
cases seemed to work for others, and blaming this on something at<br>
the OS level makes more sense than anything else that I can think<br>
of. (Another fuzzy explanation is that malloc() - when called<br>
from two threads at the same time - returned the same block of<br>
memory to both callers because of a locking problem, so two<br>
threads wound up sharing the same "pointer to semaphore".)<br>
<br>
There's a separate issue in that PROCESS-ENABLE waits for the target<br>
thread to indicate that it's "ready" with a timeout of 1 second.<br>
That's usually long enough, but it's entirely arbitrary (how long<br>
it actually takes depends on the load on and the whims of the<br>
scheduler.) Taking longer than a second might indicate that the<br>
newly-created thread isn't getting enough CPU time to signal its<br>
readiness to run, The whole notion of having a timeout for<br>
something that can take an indeterminate amount of time is<br>
questionable, so it probably makes sense to not use a one-second<br>
timeout in PROCESS-ENABLE by default, at the very least.<br>
<br>
Can you tell whether it was the first case (where PROCESS-ENABLE<br>
was waiting to enable a thread that - somehow - seems to have<br>
already been enabled) or the second (the one-second timeout is<br>
too short, and quite possibly the entire idea of a timeout is<br>
misguided) or the second ?<br>
<br>
In the former case, the thread being enabled would be on the<br>
list returned by (ALL-PROCESSES) or in the output displayed<br>
by :PROC, and in the latter case it wouldn't.<br>
<br>
On Fri, 25 Jul 2008, Milan Jovanovic wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi, i have problems with multi-threading on linux, i think it's the same<br>
like "<a href="http://trac.clozure.com/openmcl/ticket/297" target="_blank">http://trac.clozure.com/openmcl/ticket/297</a>"<br>
First it was "Unable to enable process #<PROCESS ...have been trying for<br>
</blockquote>
1<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
seconds" and inferior-list segmentation fault after 2-3 hours of running<br>
(this was on SUSE LINUX 10.0 X86-64 2.6.13-15-smp)<br>
<br>
After Gary Byers suggestion that it is meaby linux kernel bug i tried<br>
</blockquote>
on<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
SUSE Server 10 (x86_64) - kernel <a href="http://2.6.24." target="_blank">2.6.24.</a> After more then day of running<br>
with no errors i saw one more "Unable to enable process #<PROCESS<br>
</blockquote>
...have<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
been trying for 1 seconds" but this time no segmentation fault.<br>
So I'm asking is it problem/bug if this happens or only if it happens<br>
</blockquote>
with<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
segmentation fault following ?<br>
<br>
btw. i tried code on sbcl to be sure that it's not something there and<br>
</blockquote>
it's<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
running couple of days with no problems<br>
<br>
Thanks<br>
Best,Milan<br>
<br>
</blockquote>
_______________________________________________<br>
Openmcl-devel mailing list<br>
<a href="mailto:Openmcl-devel@clozure.com" target="_blank">Openmcl-devel@clozure.com</a><br>
<a href="http://clozure.com/mailman/listinfo/openmcl-devel" target="_blank">http://clozure.com/mailman/listinfo/openmcl-devel</a><br>
<br>
</blockquote>
<br>
</blockquote>
</div></div></blockquote></div><br></div>