Nicolas Neuss writes:
> David Hanley <[EMAIL PROTECTED]> writes:
>
> >
> > Well, fork can be ok in a lot of situation. On modern
> > unix systems fork() is often not much more expensive
> > than spawning a thread, if a thread work have
> > worked--that is, if they were not writing to a lot of
> > the same memory--if if the code were anemable to
> > threading, i'd guess no....
> >
> > dave
>
> My problem is the following: I have functions for solving partial
> differential equations which return a solution (quite a lot of data
> including unstructured mesh and so on) and which may take a lot of
> time (from seconds up to hours). I do not like that cmucl does not
> respond while these functions are running (e.g. when ilisp wants to
> know certain things while I edit my files). On the other hand, I want
> to have the result available for postprocessing when the function has
> terminated.
So what's your issue with inserting yeilds in the computational code?
If it's just an issue of preferring not to ... well, that's not an
option with CMUCL, unless you want to deal with the hazards of the
SIGALRM scheduler. You can always use macrology to make two versions
of your code: one that yeilds, for better interactivity; and one that
doesn't, so as not to waste cycles when you're planning on leaving the
machine.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
