Hyperion Entertainment Message Boards

About every other crash locks up the computer (or so it seems). I would assume this is because of a deadlock in intuition when the Grim Reaper wants to load.

I have a suggestion: I think intuition should track all locks to IBase and PubScreenList and all other such locks. when a task crashes the crash handler should verify if the crashed task holds any locks and if it does they should be unlocked before launching the Reaper.

In a few rare events this may create a collision which is what the locks should have prevented. However, if the survival of the running OS is in any way prioritized (which is why there is a crash handler in the first place), this is MUCH better than the *guaranteed* lockup that would otherwise happen if a task crashes with a lockup on intuition.

This is not a case of the best solution IMO, it is a matter of the least fatal solution.

...when a task crashes the crash handler should verify if the crashed task holds any locks...

And therein lies the problem. There is no way of obtaining that information with the current architecture. We're working towards it slowly but it will take time.

tonyw wrote:

...when a task crashes the crash handler should verify if the crashed task holds any locks...

And therein lies the problem. There is no way of obtaining that information with the current architecture. We're working towards it slowly but it will take time.

Well, Deniil did say "I think intuition should track all locks to IBase and PubScreenList and all other such locks", so in that scenario we would no longer be solely working within the confines of the current architechture, right? But whether such tracking, done by/in Intuition would be a logical and reasonable step on the route towards resource tracking in general in AmigaOS, I don't know.

Best regards,

Niels

Yes, I mean that intuition should implement this kind of very simple mechanism. I assume most functions imply a lock, such as OpenScreen/Window, CloseScreen/Window, not just the explicit Lock functions. Most of the time it locks up it seems to be some app that aren't handling its pubscreen properly, which becomes obvious now that we have Ringhio. Or some other silly race condition.

The same applies for dos.library since I've seen way too many times that DOS seems to lockup because of some bug in some program. Everything appears to be working but as soon as any app touches a DOS functions it freezes. At this point you obviously cannot save your work or do anything even if the mouse pointer still moves and music keeps on playing (until EOF).

The point isn't to be able to see the GrimReaper. The point is that the OS shouldn't freeze for silly programming mistakes.

It simply needs to become more rubust, resource tracking or not. Semaphore timeouts could possibly be an intermediate solution.

Here's a solution - make Workbench the owner of all resource allocations done by processes it spawned, which will be most if not all of the end user facing apps a user runs. So basically each library, font, boopsi class, window, gadget, screen, icon, file handle etc all belong to workbench, and each of the allocate/deallocate functions for those start with an 'if process is spawned by workbench, tell workbench to allocate it, reference count, and hand the pointer to the process'. Then if the process is unloaded, which workbench can do because it spawned it, workbench does the cleanup on that processes resources.