Re: [Caml-list] Re: Road to native windows OCaml...

[Kuba Ober <kuba@mareimbrium.org>]

> > Why do we need fork? I need to look at the code...
>
> http://caml.inria.fr/pub/ml-archives/caml-list/1999/03/f44178e212e78826bcbd
>ee52ddf6fd91.en.html
>
> Concerning bytecode debugging under Windows, the major issue is the
> way our debugger performs periodic checkpointing of the running program
> (in order to implement reverse execution).  We just use the Unix fork()
> system call, which does everything we want (checkpointing of memory
> and file descriptors, using lazy copy-on-write to minimize copying).

Ah-ha, hmm, I guess I will just have to hack on some "state-preserving"
machinery for win32 world, then. That's way into the future, but should
be doable. Some things cannot be trivially preserved unless you instrument
(wrap) the relevant APIs. Example: on Unices, you can read from a network
stream, fork, and continue on reading in the child process. The parent
process can stop reading and resume at a later point: the kernel will buffer
the data as long as it can (till it runs out of memory). On Windows, this
is not doable without wrapping the relevant Winsock calls, and potentially
all other streaming interfaces that the OCaml application uses either
directly or indirectly.

The checkpointing for OCaml's debugging can perform much better than Cygwin's
fork because the bytecode interpreter controls the application startup and
can put everything (including itself) into memory pages that can be made
copy-on-write at checkpoints. The only benefit to creating separate processes
for each checkpoint is to have more virtual memory available, and to prevent a
crash from doing too much damage. Even then, enough functionality should be
easy to implement to make this feature "do what you expect it to" on Windows.

It's still some work to get it to work, but what the heck: may as well prove
to myself it's doable. That'd come after Camelia is in shape, though.

Cheers, Kuba