Changes by: Jason J. Hickey (jyh at cs.caltech.edu)
Date: 2007-07-15 10:50:21 -0700 (Sun, 15 Jul 2007)
Revision: 11273
Log message:

      The ml_print_string function was truncating strings.
     This addresses bug #685.
     
     It would be nice to get the string length calculation really
     right, so truncation would never happen.
     
     The following will truncate if snprintf exists, and probably
     segfault if not.
     
        $(sprintf %100000s, a)

Changes by: Jason J. Hickey (jyh at cs.caltech.edu)
Date: 2007-07-15 10:55:23 -0700 (Sun, 15 Jul 2007)
Revision: 11274
Log message:

      Also: pass the calculated width to the ml_print_string function
     to avoid truncation.

Changes by: Aleksey Nogin (nogin at metaprl.org)
Date: 2007-07-16 12:13:43 -0700 (Mon, 16 Jul 2007)
Revision: 11279
Log message:

      Implemented Lm_unix_util.getlk that returns the PID of the process holding the
     lock (untested).

Changes by: Aleksey Nogin (nogin at metaprl.org)
Date: 2007-07-16 13:21:01 -0700 (Mon, 16 Jul 2007)
Revision: 11280
Log message:

      Lm_unix_util.getlk - give more precise error messages.

Changes by: Aleksey Nogin (nogin at metaprl.org)
Date: 2007-07-16 14:10:43 -0700 (Mon, 16 Jul 2007)
Revision: 11282
Log message:

      Make the "In binary mode, the write_buffer is the same as the out_buffer."
     into a proper invariant, which is maintained even when the current version of
     the code does not really care.

Changes by: Jason J. Hickey (jyh at cs.caltech.edu)
Date: 2007-07-17 15:09:06 -0700 (Tue, 17 Jul 2007)
Revision: 11306
Log message:

      Change some ext_print_string to ext_print_string2.

Changes by: Aleksey Nogin (nogin at metaprl.org)
Date: 2007-07-18 10:42:32 -0700 (Wed, 18 Jul 2007)
Revision: 11318
Log message:

      The "not supported" version of the lm_getlk function is needed on Windows as well.

Changes by: Aleksey Nogin (nogin at metaprl.org)
Date: 2007-07-18 12:38:39 -0700 (Wed, 18 Jul 2007)
Revision: 11323
Log message:

      Minor - use CheckCode correctly.

Changes by: Aleksey Nogin (nogin at metaprl.org)
Date: 2007-07-18 12:59:48 -0700 (Wed, 18 Jul 2007)
Revision: 11325
Log message:

      Minor simplification.

Changes by: Jason J. Hickey (jyh at cs.caltech.edu)
Date: 2007-07-18 13:47:08 -0700 (Wed, 18 Jul 2007)
Revision: 11326
Log message:

      Additional fix to lm_make_printf -- I have no idea why the previous worked for me.

Changes by: Jason J. Hickey (jyh at cs.caltech.edu)
Date: 2007-07-18 14:05:29 -0700 (Wed, 18 Jul 2007)
Revision: 11327
Log message:

      One more attemkpt on lm_make_printf.

Changes by: Jason J. Hickey (jyh at cs.caltech.edu)
Date: 2007-07-18 14:06:42 -0700 (Wed, 18 Jul 2007)
Revision: 11328
Log message:

      Fixed typo.

Changes by: Aleksey Nogin (nogin at metaprl.org)
Date: 2007-07-18 15:09:10 -0700 (Wed, 18 Jul 2007)
Revision: 11331
Log message:

      [Bug 535] Handle Sys.Break ("Ctrl-C") events in thread pools - basically, once any of the threads in the jobs in the pool dies with a Ctrl-C, the whole pool becomes "poisoned" - any attempt to call wait/waitpid/create will raise the Sys.Break exception.
     
     Eventually, we should probably allow the pool to recover. Or, better yet, we should make the pool itself an explicit parameter, thus making it possible to close the "poisoned" pool, letting it die and open a fresh one instead.

Changes by: Aleksey Nogin (nogin at metaprl.org)
Date: 2007-07-19 10:45:28 -0700 (Thu, 19 Jul 2007)
Revision: 11355
Log message:

      A small optimization of the multi-thread locking mechanisms in Lm_hash.

Changes by: Aleksey Nogin (nogin at metaprl.org)
Date: 2007-07-19 12:19:39 -0700 (Thu, 19 Jul 2007)
Revision: 11356
Log message:

      Trying to debug the deadlocks I am seeing on Windows when -p is enabled. What I am seeing is that the worker threads are being created, but they never start (even the child part of the Lm_thread.create_thread is never executed). I have no idea how the -p causes this...
     
     In this commit I:
     - Added a lot of thread-related debugging code
     - Made the -debug-thread command-line option also activate Lm_thread.debug_lock and Lm_thread_code.debug_mutex (the latter variable is new).
     - Changed the Lm_thread_core_null so that Lm_thread.Mutex.try_lock would return a value consisntent with the real thread implementation.

Changes by: Aleksey Nogin (nogin at metaprl.org)
Date: 2007-07-19 12:22:34 -0700 (Thu, 19 Jul 2007)
Revision: 11357
Log message:

      Fixing a Unix-only non-compile.

Changes by: Aleksey Nogin (nogin at metaprl.org)
Date: 2007-07-19 13:13:39 -0700 (Thu, 19 Jul 2007)
Revision: 11359
Log message:

      Minor no-op change - have Lm_notify.file_descr return an option and leave it
     up to Omake_exec_notify to fake it with a Unix.stdin, if necessary.

Changes by: Aleksey Nogin (nogin at metaprl.org)
Date: 2007-07-19 13:36:15 -0700 (Thu, 19 Jul 2007)
Revision: 11360
Log message:

      Couple extra debugging printouts.

Changes by: Aleksey Nogin (nogin at metaprl.org)
Date: 2007-07-19 14:06:05 -0700 (Thu, 19 Jul 2007)
Revision: 11361
Log message:

      The debug code was broken, sorry.

Changes by: Jason J. Hickey (jyh at cs.caltech.edu)
Date: 2007-07-23 12:59:55 -0700 (Mon, 23 Jul 2007)
Revision: 11387
Log message:

      Revert Lm_thread.Mutex.create : unit -> Mutex.t (not string -> Mutex.t).

Changes by: Aleksey Nogin (nogin at metaprl.org)
Date: 2007-07-23 15:24:05 -0700 (Mon, 23 Jul 2007)
Revision: 11389
Log message:

      Changed Lm_thread.Mutex.create back to string -> t. Hopefully now everything
     compiles for everybody.

Changes by: Aleksey Nogin (nogin at metaprl.org)
Date: 2007-07-23 15:33:20 -0700 (Mon, 23 Jul 2007)
Revision: 11390
Log message:

      Added a few files to the compile list to prevent them from going stale in case
     we need them again.

Changes by: Jason J. Hickey (jyh at cs.caltech.edu)
Date: 2007-07-27 10:58:13 -0700 (Fri, 27 Jul 2007)
Revision: 11467
Log message:

      Grrr, I should know better than this.  Fixed an issue where the CheckCode
     macro in lm_notify.c was not being parenthesized.
     
     This fixes bug #687.

Changes by: Aleksey Nogin (nogin at metaprl.org)
Date: 2007-07-27 12:35:18 -0700 (Fri, 27 Jul 2007)
Revision: 11470
Log message:

      Be more eager to unlock the "big lock" on receiving a Ctrl-C.

Changes by: Jason J. Hickey (jyh at cs.caltech.edu)
Date: 2007-07-27 15:11:57 -0700 (Fri, 27 Jul 2007)
Revision: 11476
Log message:

      Hmmm, there is a type change in 3.10.  I should probably check
     for 3.09 also.

Changes by: Aleksey Nogin (nogin at metaprl.org)
Date: 2007-07-31 13:10:41 -0700 (Tue, 31 Jul 2007)
Revision: 11496
Log message:

      [Bug 535] Added a hack to address the "Sys.Break does not get raised inside C
     blocking sections" problem (see
     http://caml.inria.fr/pub/ml-archives/caml-list/2007/07/3662ad69f77253674f580b174c85dfbb.en.html
     for detail).
     
     My "solution" is that when threads are enabled, the Lm_notify.next_event would
     run in a child thread, while the master thread periodically (currently - at
     0.1s intervals) checks whether it's done. If Ctrl-C is pressed, OCaml will
     interrupt the master thread with Sys.Break, which is what we want.
     
     Note that simply having the master thread wait for the child one does not work
     - we need the master thread to execute caml_leave_blocking_section()
     regularly!
     
     P.S. I have only tested this on Unix with threads enabled, will test on
     Windows next.

Changes by: Aleksey Nogin (nogin at metaprl.org)
Date: 2007-07-31 14:08:57 -0700 (Tue, 31 Jul 2007)
Revision: 11498
Log message:

      Added a helper function pp_print_any_list.