<div class="gmail_quote">On Wed, Mar 28, 2012 at 3:25 AM, Daniel Herring <span dir="ltr"><<a href="mailto:dherring@tentpost.com">dherring@tentpost.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">The exact same issue occurs with condition variables.  As a result, the caller of pthread_cond_signal frequently needs to use the same mutex as the caller of pthread_cond_wait.</div></blockquote><div><br>
</div>
<div>Yes, I know, but condition variables are really not a good primitive type. They are not portable and they already involve two system objects: mutexes and the variable itself.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Random idea; I don't like it; but maybe it will spark a good one. If ECL spawned a dedicated "kernel" process</blockquote><div><br></div><div>I have thought about it. We already have an extra thread for signal handling, and could be reused. But if possible, then this thread should be sleeping as long as possible, because that one might end up being the CPU hog.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Another idea.  I've seen a people advocate using UNIX sockets as a synchronization mechanism in some circumstances.  Write a byte as a signal.  The receiving process can use a blocking read() and still be woken by interrupts.  Different efficiency tradeoffs than the polling loop.  Harder to get lost between 1 and 2, but introducing other problems.<br>

</blockquote><div><br></div><div>Sounds like a reasonable compromise, but would require one socket per mutex at least.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Can't you use pthread_mutex_trylock to query whether a thread is locked? Not super efficient, but it should work.<br></blockquote><div><br></div><div>The problem is not really to know whether the mutex is locked, but whether it is locked by our thread. Think of a call to WITH-LOCK. It relies on pthread_mutex_lock() but the call gets interrupted and it jumps out of the system routine with THROW, RETURN, etc. How does WITH-LOCK know whether it has to release the lock? Checking with trylock does not work because another thread might have locked in the time that passed between the interrupt and the actual check.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Similarly, might it be possible to use pthread_mutex_timedlock, and use it in a polling loop to check whether any interrupts have been delivered?<br></blockquote><div><br></div><div>This ends up being like our atomics implementations where the atomics and the nanosleep() are packed together.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In these issues, I sometimes think the user's expectations cannot be satisfied, and that they really need something slightly different than what they are asking for.  Could you remind me of the thread where this interrupt/mutex issue came up?  Is it basically the clean shutdown / "Control-C" to wake a hung process issue, or something deeper?</blockquote>

<div><br></div><div>Basically it is the expectation that Common Lisp processes can be interrupted, that a thread can be killed and that during interactive development one may stop a blocking process that is waiting on a mutex. Things like these. In other worlds (C/C++), these requirements do not exist because programs are simply killed, debugged and restarted.</div>

<div><br></div><div>I myself would live much more happily if all the Lisp interrupt business disappeared, but it is out there and making ECL be the only implementation that does not support them would be like shooting on our own feet.</div>

</div><div><br></div>Juanjo<br clear="all"><div><br></div>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com" target="_blank">http://juanjose.garciaripoll.googlepages.com</a><br>