<div dir="ltr">I think that it's the case when process-enable tries to enable process that is already running.<br>If i am getting this right  from manual process-run-function is using process-enable when creating process and my case is that I am creating fixed number of worker processes at the start of program and those messages/errors I get after hours of working (and not creating processes no more) so why process-enable then ?<br>
If i get this completely wrong ... sorry :)<br><br><div class="gmail_quote">On Fri, Jul 25, 2008 at 10: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] 35 :    Worker thread  [semaphore wait]  (Requesting terminal input)<br>
14 :    Worker thread  [semaphore wait] 1 : -> listener     [Active] 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. 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.<div><div></div><div class="Wj3C7c"><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 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>
</blockquote>
</div></div></blockquote></div><br></div>