Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] ocamldebug and windows
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-10-22 (07:57)
From: Xavier Leroy <xavier.leroy@i...>
Subject: Re: [Caml-list] ocamldebug and windows
> > You need a bit more than this: file and socket handles also need some
> > checkpointing (of the kind that fork() does on file descriptors in the
> > Unix world).
> Really? Correct me if I am wrong, but fork() should care of the proper
> handle copying because it creates the new child process, that should be in
> the same state. But I suggest to use the only process, just save/restore
> its state somethere when needed. This way the memory dump seems to be
> sufficient, no?

I'm afraid not.  Consider the following program:

    time t1:  open file /tmp/foo, obtaining file handle #3 (for instance)
    time t2:  work on this file handle
    time t3:  close file handle
    time t4:

Assume we're at time t4, and want to go back to the checkpoint at time
t2.  With the solution you outline, file handle #3 is closed and
re-executing the code between t2 and t3 fails.

It is true that time-travel in the presence of I/O is, in general,
impossible.  (You can't "un-send" the network packets that were
already sent!)  However, I'd like it to work at least for programs
that read or write regular files, as in the example above.  Under
Unix, fork() gets us 90% there -- there is still an issue with the
reading/writing position being shared (not duplicated) between the
parent and child process, but we are considering hacks to work around

- Xavier Leroy
To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: