From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA09801; Thu, 27 May 2004 11:34:11 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 LAA09839 for ; Thu, 27 May 2004 11:34:10 +0200 (MET DST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i4R9Y6EV032058 for ; Thu, 27 May 2004 11:34:08 +0200 Received: from [192.168.1.200] (ppp114-11.lns1.syd3.internode.on.net [150.101.114.11]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i4R9XZZq047120; Thu, 27 May 2004 19:03:52 +0930 (CST) Subject: Re: [Caml-list] unix.chop_extension From: skaller Reply-To: skaller@users.sourceforge.net To: Markus Mottl Cc: Richard Jones , Ocaml In-Reply-To: <20040527074634.GA27994@fichte.ai.univie.ac.at> References: <1085429093.6065.336.camel@pelican.wigram> <20040526110508.A17806@pauillac.inria.fr> <40B47D9D.1050007@baretta.com> <20040526164308.GA22145@redhat.com> <1085633313.32106.110.camel@pelican.wigram> <20040527074634.GA27994@fichte.ai.univie.ac.at> Content-Type: text/plain Message-Id: <1085650415.32106.357.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 27 May 2004 19:33:35 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 40B5B60E.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 chop:01 sourceforge:01 2004:99 pcre:01 pcre:01 thread-safe:01 thread-safe:01 callbacks:01 invocations:01 c-library:01 initialized:01 constants:01 vyper:01 9660:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Thu, 2004-05-27 at 17:46, Markus Mottl wrote: > On Thu, 27 May 2004, skaller wrote: > > AFAIK: The C Pcre that it wraps does use global variables > > and so while the interface appears re-entrant > > it isn't. > > To prevent people from getting a false impression of PCRE as interfaced > to OCaml: it _is_ safe. You are using the word 'safe' imprecisely. Reentrant is specific. So is thread-safe. Re-entrant + no shared data structures implies thread-safe. Thread safe doesn't imply re-entrant. In particular, re-entrant is a stronger condition in the sense that it implies all callbacks including asynchronous invocations from signal handlers will work: thread safe code may deadlock here. > The use of global variables by the C-library does not necessarily imply > that the program is unsafe. It all depends on their use, and in this > case the global variables (e.g. pcre_callout) are initialized exactly > once at startup time, i.e. before the user can access any functions. If this is so, the globals are merely constants, and the code will be re-entrant after the initialisation is complete. However my examination of the C Pcre at one time showed this was NOT the case. Instead, certain options were stored in global variables on every call, and that implies the code isn't re-entrant and cannot ever be made so. I may have been wrong, and perhaps I was right but Pcre has changed: I last looked some years ago whilst working on Vyper .. As Markkus comments use of imperative style is not the issue here. A function can easily modify variables and be re-entrant provided the variables are (rooted) on the stack. -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners