source.squeak.org stuck Mutex again

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

source.squeak.org stuck Mutex again

Chris Muller-3
The source.squeak.org server got stuck on a Mutex again.  Here's a
picture of the waiting processes on the server, along with an
inspector on the Mutex.

Back when Mutex was pure Smalltalk if this happened I could just
signal its internal Semaphore and off it would go, delayed processes
would eventually run.  But it's all hidden in the VM now, so the only
viable thing I can do is restart the image.



how-to-manually-signal-mutex.png (448K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: source.squeak.org stuck Mutex again

David T. Lewis
On Fri, Apr 20, 2018 at 05:08:52PM -0500, Chris Muller wrote:
> The source.squeak.org server got stuck on a Mutex again.  Here's a
> picture of the waiting processes on the server, along with an
> inspector on the Mutex.
>
> Back when Mutex was pure Smalltalk if this happened I could just
> signal its internal Semaphore and off it would go, delayed processes
> would eventually run.  But it's all hidden in the VM now, so the only
> viable thing I can do is restart the image.

This is a complete shot in the dark, and you probably have already
done this, but would sending #primmitiveExitCriticalSection to the
mutex do the trick?

Dave


Reply | Threaded
Open this post in threaded view
|

Re: source.squeak.org stuck Mutex again

Chris Muller-3
No, I didn't, I guess I ignored the #prim methods but maybe I
shouldn't.  Reading the comment, it looks like that might've worked...



On Fri, Apr 20, 2018 at 6:14 PM, David T. Lewis <[hidden email]> wrote:

> On Fri, Apr 20, 2018 at 05:08:52PM -0500, Chris Muller wrote:
>> The source.squeak.org server got stuck on a Mutex again.  Here's a
>> picture of the waiting processes on the server, along with an
>> inspector on the Mutex.
>>
>> Back when Mutex was pure Smalltalk if this happened I could just
>> signal its internal Semaphore and off it would go, delayed processes
>> would eventually run.  But it's all hidden in the VM now, so the only
>> viable thing I can do is restart the image.
>
> This is a complete shot in the dark, and you probably have already
> done this, but would sending #primmitiveExitCriticalSection to the
> mutex do the trick?
>
> Dave
>
>