<div dir="ltr">In the case described, when I (:y 35), and type :go (or whatever made the lisp system ignore the warning), IIRC, it all worked.  Therrefore, IIRC, it's probably the latter, where one second isn't enough (or something new is 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 just started happening when I upgraded to the RC verson of CCL (RC 1.2?).  I can inquire of our IT department if you would find whether there was an OS change during this period to be relevant information.  RC 1.2 fixed another OpenMCL problem (which I was quite pleased about), so it wasn't like I could just keep using the old OpenMCL.<br>
<br>At least now our group is no longer the only group seeing and reporting this behavior.<br><br><div class="gmail_quote">On Fri, Jul 25, 2008 at 1:25 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;">In the original bug report, the backtrace for what was thread #35 showed<br>
<br>
  (2AAAAD619B18) : 0 (PROCESS-ENABLE #<PROCESS Worker thread(38) [Active] #x300043A1C8ED> [...]) 405<br>
  (2AAAAD619B68) : 1 (%PROCESS-RUN-FUNCTION '(:NAME "Worker thread") #<COMPILED-LEXICAL-CLOSURE (:INTERNAL ACL2::RUN-THREAD) #x300043A1CD7F> NIL) 1373<br>
  (2AAAAD619C58) : 2 (PROCESS-RUN-FUNCTION "Worker thread" #<COMPILED-LEXICAL-CLOSURE (:INTERNAL ACL2::RUN-THREAD) #x300043A1CD7F> [...]) 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>
<div><div></div><div class="Wj3C7c"><br>
On Fri, 25 Jul 2008, Milan Jovanovic wrote:<br>
<br>
> 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 1<br>
> 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  on<br>
> 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 ...have<br>
> 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 with<br>
> segmentation fault following ?<br>
><br>
> btw. i tried code on sbcl to be sure that it's not something there and it's<br>
> running couple of days with no problems<br>
><br>
> Thanks<br>
> Best,Milan<br>
><br>
</div></div>_______________________________________________<br>
Openmcl-devel mailing list<br>
<a href="mailto:Openmcl-devel@clozure.com">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>
</blockquote></div><br></div>