Re: problem with trainin since upgrade to blamethesegfault

   From: "Ger Hobbelt" <[email protected]>

   >  Hmmm...  I wonder if I can do a bit of fork magic here, and have
   >  the forked instance check the FLAGS, and if the user has requested
   >  it, re-init the engine and then load a new program, preprocess it,
   >  JIT it, and start the new program executing...?
   >
   >  That would also be a big win for demonization.
   >
   >  Let me think on this.

   Okidoki.

   Erm, one thing: 'fork' is not really all that nice for my Win32 port
   at the moment (because I'm too lazy to add _that_ particular bit of
   support just yet), so I'ld like to ask you if you could think more in
   terms of turning mailtrainer into a library-like script, say,
   mailtrainlib.crm, which is than 'insert'-ed in the mailreaver.crm and
   mailtrainer.crm scripts.
   Since mailreaver waits for mailtrainer anyhow, the 'in-line' library
   single thread approach is identical in terms of performance to a
   fork()ed one.

   Just my 2 cents in trying to stay partially lazy ;-)

Oh, this is worth it.

The reason to go fork rather than a single-threaded library call is
that there are probably variable name clashes between mailreaver and
mailtrainer (they started out from sorta the same code base, and 
hence have overlapping variable names).

That's why it might be easier to actually get fork() working than
the other way 'round.

Every OS that supported multiprocessing I ever used has had a fork()
or equivalent (even OS/360; you sent card images to the internal
reader and they got put in the job queue.  Woe be the person who
submitted a job that submitted two copies of itself...)

    - Crash

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone