From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id IAA04993 for caml-red; Thu, 30 Nov 2000 08:55:24 +0100 (MET) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id CAA08602 for ; Thu, 30 Nov 2000 02:16:51 +0100 (MET) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by nez-perce.inria.fr (8.11.1/8.10.0) with SMTP id eAU1Go515895 for ; Thu, 30 Nov 2000 02:16:50 +0100 (MET) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 29 Nov 2000 16:57:29 -0800 (Pacific Standard Time) Received: by inet-imc-04.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Wed, 29 Nov 2000 15:25:40 -0800 Message-ID: From: Manuel Fahndrich To: "'gerd@gerd-stolpmann.de'" , Ken Wakita , jserot@lasmea.univ-bpclermont.fr Cc: caml-list@inria.fr Subject: RE: Marshaling of custom blocks and threads Date: Wed, 29 Nov 2000 14:34:13 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: weis@pauillac.inria.fr Here's another point to consider. I just submitted a bug report concerning serialization of custom blocks (I assume marshalling uses the serialization code). The deserialization code for custom blocks does not correctly reproduce sharing. Try writing a tuple of the same int64 data structure and reading it back via output_value, input_value. The second component of the built tuple is garbage. I submitted a fix which works for me: Add: At line 266 in file byterun/intern.c, insert the following line: if (intern_obj_table != NULL) intern_obj_table[obj_counter++] = v; There's a int64 related bug in byterun/ints.c. Change line:282 of byterun/ints.c < *wsize_64 = *wsize_64 = 8; > *wsize_32 = *wsize_64 = 8; This bug caused the size of the block to be allocated when reading int64 data back in to be wrong on 32bit architectures. -Manuel -----Original Message----- From: Gerd Stolpmann [mailto:gerd@gerd-stolpmann.de] Sent: Tuesday, November 28, 2000 5:22 PM To: Ken Wakita; jserot@lasmea.univ-bpclermont.fr Cc: caml-list@inria.fr Subject: Re: Marshaling of custom blocks and threads On Tue, 28 Nov 2000, Ken Wakita wrote: >I think the Marshal module is thread unsafe because it uses a shared >buffer to produce the external image of the ML objects. In 2.04, this was definitely true (see http://caml.inria.fr/bin/caml-bugs/fixed?id=24;page=1;user=guest and http://caml.inria.fr/bin/caml-bugs/fixed?id=25page=1;user=guest). However, the bug was still subtle; the shared buffers were relatively well protected by the so-called "master lock". Until now, I thought that 3.00 fixed the bug finally; i.e. the master lock really locked the shared buffer. (I checked the code.) Jocelyn Serot reports that Marshal is not thread-safe for custom blocks. These did not exist in 2.04, so I suppose that only the new parts of the marshalling system do not work properly enough. However, multi-threading programming is error-prone, so it would be helpful to have a small program that demonstrates the bug (normally it is sufficient to repeat the errorneous piece of code often enough (e.g. 10000 times) to reproduce the incorrect behaviour). Gerd -- ---------------------------------------------------------------------------- Gerd Stolpmann Telefon: +49 6151 997705 (privat) Viktoriastr. 100 64293 Darmstadt EMail: gerd@gerd-stolpmann.de Germany ----------------------------------------------------------------------------