English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Why 'Graphics.wait_next_event' doesn't reply anymore ?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-11-12 (06:18)
From: Oliver Bandel <oliver@f...>
Subject: Re: [Caml-list] Why 'Graphics.wait_next_event' doesn't reply anymore ?
Zitat von Fabrice Marchant <fabrice.marchant@orange.fr>:

>   Hi Oliver !
>  Thanks to have considered my problem.
> On Sun, 11 Nov 2007 17:48:34 +0100
> Oliver Bandel <oliver@first.in-berlin.de> wrote:
> >
> > This code looks ugly.
> ...
> > It forces calls to the scheduler all too often.
> > And it does it at three places. And in the print-loop
> > it clals it every time!
> > This is the way of wasting ressources.
>   I think these 'yields' are only desperate attempts to hint the scheduler to
> do its job - that it doesn't as we could expected -.

Yes, that also was my view on using this function to often.

It's like using OCaml: ehy to use the GC-Module?
I have not used it, because I didn't needed.
I first look, if my code could possibly done better,
instead of thinking the gaerbageCollector might do something wrong.

The Gc-module is there to have a possibility to use some
screws for manual fine-tuning. But you should not start to
use it until your application seems to be ready.

It's like in LaTeX, where you should not too often
look at the results of line braking. You can do fine tuning
at the end.

And Gc or in Threading: explicit hints to the scheduler
should be used, if necessary, and not as early as possible.

But these are very general hints: optimization of details
comes at the end.

Best way to avoid "problems that have to be fixed by hand later"
(workarounds) is, to have some consideration on the design when
you start (and during the whole development phase of course).

(In LaTeX: use the pramble for selecting the right class and packages
and do not insert paragraph spacing throughout the whole document, if you
can change \parskip and \parindent ;-))


P.S.: And looking for Bugfixes in the libraries (as the one with the
      example code of "toto.ml") is the thing that comes in the very end,
      when the code is really good. If someone writes bad code and then
      looking for bugfixes of the langaueg he/she uses, that's a littlebid
      strange, IMHO.
      For concurrent programming you need to rethink many things, compared to
      non-concurrent programming. It's a littlebid like switching to FP,
      coming from non-FP-languages.