Duncan Coutts writes:
you cannot solve the finalisers problem just by running
the finaliser thread to completion (or it'd be done that
way already!)
I guess, I was approaching the problem from the wrong side.
What I am really interested in are the implications of this
fact for the
How can I put this, it is a best efforts approach - it does its best
to run the
finalizers, even after a segmentation fault... however some of the
pointers may
be messed up... If the cleanup causes a segmentation fault (sometimes called
a double bus fault) then we have to abandon the cleanup.
On 22 November 2004 17:28, Benjamin Franksen wrote:
I understand that there are situations where finalizers cannot be
guaranteed to run: First because of an unconditional termination
signal (SIGKILL), second because of circular dependencies resulting
in a deadlock.
I don't understand why
Simon Marlow wrote:
Note that the GC only starts the finaliser thread. The program can
still terminate before this thread has run to completion (this is one
reason why we say that finalisers don't always run before program
termination).
This sounds like a bug to me... surely you should wait
On Tuesday 23 November 2004 13:06, Simon Marlow wrote:
On 22 November 2004 17:28, Benjamin Franksen wrote:
I understand that there are situations where finalizers cannot be
guaranteed to run: First because of an unconditional termination
signal (SIGKILL), second because of circular
On 23 November 2004 13:46, Keean Schupke wrote:
Simon Marlow wrote:
Note that the GC only starts the finaliser thread. The program can
still terminate before this thread has run to completion (this is one
reason why we say that finalisers don't always run before program
termination).
Simon Marlow writes:
Note that the GC only starts the finaliser thread. The
program can still terminate before this thread has run
to completion [...]
If you want anything else, you can implement it.
How do I implement that particular feature? I don't see how
I could write a 'main'
On Tue, 2004-11-23 at 18:01 +0100, Peter Simons wrote:
Simon Marlow writes:
Note that the GC only starts the finaliser thread. The
program can still terminate before this thread has run
to completion [...]
If you want anything else, you can implement it.
How do I implement that
On 20 November 2004 23:02, Benjamin Franksen wrote:
I am using Foreign.Concurrent.newForeignPtr and touchForeignPtr
inside the finalizers to express liveness dependencies as hinted to
by the documentation. This doesn't seem to work, though, or at least
I can't see what I've done wrong. I
Some thoughts on this,
Whilst I agree that finalizers are best avoided, it must be possible to
order the finalizers for running on exit... Perhaps a simple multi-pass
algorith would do? (ie: run all finalizers that do not refer to other
objects
with finalizers - repeat until no objects with
Keean Schupke wrote:
[...]
Whatever happens I think it must make sure all system resources allocated
by a program are freed on exit - otherwise the machine will have a resource
leak and will need rebooting eventually.
That's an OS task IMHO, not really the task of an RTS. Looks like you're
working
Nope there are some unix resources that c exit routines do not free
like semaphores.
Sven Panne wrote:
Keean Schupke wrote:
[...]
Whatever happens I think it must make sure all system resources
allocated
by a program are freed on exit - otherwise the machine will have a
resource
leak and will
On Monday 22 November 2004 14:45, Simon Marlow wrote:
On 20 November 2004 23:02, Benjamin Franksen wrote:
I am using Foreign.Concurrent.newForeignPtr and touchForeignPtr
inside the finalizers to express liveness dependencies as hinted to
by the documentation. This doesn't seem to work,
If finalizers are not the right thing, what else is?
I've found that when writing an interface to a C library that requires
resource management, it's much better to use the withX (see
Control.Exception.bracket) style of function than to use finalizers -
programs are much easier to reason about
Abraham Egnor wrote:
I've found that when writing an interface to a C library that requires
resource management, it's much better to use the withX (see
Control.Exception.bracket) style of function than to use finalizers -
programs are much easier to reason about and debug.
... and have a much more
Keean Schupke wrote:
Nope there are some unix resources that c exit routines do not free
like semaphores.
Which library/OS calls do you mean exactly? I always thought that files
are the only resources surviving process termination.
Cheers,
S.
___
Semaphores (SYSV style) are not freed automatically. Currenly I am using
C's at_exit funtion (which is even called on a signal)... Perhaps this
is the
way to deal with foreign resources... bracket notation and at_exit to clean
up on signals?
Keean.
Sven Panne wrote:
Keean Schupke wrote:
Nope
On Monday 22 November 2004 18:55, Sven Panne wrote:
Abraham Egnor wrote:
I've found that when writing an interface to a C library that requires
resource management, it's much better to use the withX (see
Control.Exception.bracket) style of function than to use finalizers -
programs are
Keean Schupke wrote:
C exit routines aren't responsible for freeing OS resources; the OS
is.
The fact that the SysV IPC objects aren't freed on exit is
intentional; they are meant to be persistent. For the same reason, the
OS doesn't delete upon termination any files which the
Although, this does remind me.
A suitable atexit-equivalant in the haskell libraries would be much appreciated.
John
--
John Meacham - repetae.netjohn
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
Hi,
I am using Foreign.Concurrent.newForeignPtr and touchForeignPtr inside the
finalizers to express liveness dependencies as hinted to by the
documentation. This doesn't seem to work, though, or at least I can't see
what I've done wrong. I attached a test module; compiled with ghc
21 matches
Mail list logo
