Pixel <[EMAIL PROTECTED]> writes:
> what about running the garbage collector for such errors, just in
> case it can help? all resources that can be freed by the garbage
> collector should trigger a GC when that resource is low, uh? (maybe
> that's what ghc-5.02 is doing since i've not been able to reproduce
> the pb after increasing the heap)
This is exactly what Hugs does with file handles.
It's also what we did in FVision (a visual tracking system) for image
handles. Each handle pointed to a large (perhaps 2Mb) image. If you
didn't release the handles very promptly, you ran out of physical
memory or even virtual memory. This didn't do a lot for the desired
real-time behaviour of the system so we explicitly kept track of the
number of outstanding objects and triggered a GC whenever the number
exceeded some threshold.
Simply relying on performing regular GCs is inadequate because _the
amount of work you've done in Haskell has little or nothing to do with
the amount of resources you've allocated outside of Haskell_.
The problem I see in doing the same thing in GHC is that performing a
GC does not release the external objects - it merely schedules a
thread which will release the external object. This means you really
have to do something like this:
T allocate()
{
if (resources < LIMIT) {
gc();
allocator_blocked = 1;
sleep_until_finalizer_wakes_me();
allocator_blocked = 0;
}
resources--;
return raw_allocate();
}
and then each of the finalizers does something like this:
void finalize()
{
resources++;
if (resources >= LIMIT && allocator_blocked) {
wakeup_blocked_allocator();
}
}
[Lots of details like avoiding race conditions omitted.]
--
Alastair Reid [EMAIL PROTECTED] http://www.cs.utah.edu/~reid/
_______________________________________________
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
