caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Markus Mottl <mottl@miss.wu-wien.ac.at>
To: Gerd Stolpmann <gerd@gerd-stolpmann.de>
Cc: Miles Egan <miles@caddr.com>, OCAML <caml-list@inria.fr>
Subject: Re: features of PCRE-OCaml
Date: Sat, 9 Dec 2000 04:03:15 +0100	[thread overview]
Message-ID: <20001209040315.D26367@miss.wu-wien.ac.at> (raw)
In-Reply-To: <00120816434509.00625@ice>; from gerd@gerd-stolpmann.de on Fri, Dec 08, 2000 at 16:40:53 +0100

Gerd Stolpmann schrieb am Friday, den 08. December 2000:
> There are two functions making it easy: enter_blocking_section and
> leave_blocking_section. For example, the stub for the read syscall of the Unix
> library:

Ok, I have found an article by Xavier on these functions:

  http://caml.inria.fr/archives/199905/msg00035.html

So if I am not mistaken, a function that calls the GC or allocates memory
on the OCaml-heap cannot be considered reentrant even if its semantics
is otherwise referentially transparent. This means that just "tagging"
a function as "pure" is no guarantee that it won't mess up the runtime
when e.g. calling the GC concurrently - right?

In other terms I can put those functions around the largest section of
C-code that doesn't interfere with the OCaml-runtime system - then I
should be safe.

The only question now is: would it really pay for pattern matching in the
PCRE? I have taken a look at the implementation of these functions and on
their use, but have only found cases where some function really blocks for
either an indefinite (e.g. read) or at least potentially very long amount
of time (e.g. gethostbyaddr, which might need to contact a nameserver).

Without threads we won't benefit, anyway, and if we use threads, there
is a small overhead associated with calling these functions. Pattern
matching maybe does not eat up so much time in the average case that this
is justified. Any experiences or suggestions when using these functions
is advisable?

- Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl



  reply	other threads:[~2000-12-11 17:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-06  0:51 Markus Mottl
2000-12-07 16:01 ` John Max Skaller
2000-12-07 16:32   ` Markus Mottl
2000-12-07 17:08     ` John Max Skaller
2000-12-08  0:03       ` Markus Mottl
2000-12-08 17:52         ` John Max Skaller
2000-12-08  9:19       ` Alain Frisch
2000-12-08 18:11         ` John Max Skaller
2000-12-08 19:48           ` Alain Frisch
2000-12-09 17:07             ` John Max Skaller
2000-12-14 17:35   ` unicode support Nickolay Semyonov
2000-12-07 20:17 ` features of PCRE-OCaml Miles Egan
2000-12-08 12:30   ` Gerd Stolpmann
2000-12-08 15:05     ` Markus Mottl
2000-12-08 15:40       ` Gerd Stolpmann
2000-12-09  3:03         ` Markus Mottl [this message]
2000-12-09 13:12           ` Gerd Stolpmann
2000-12-10  0:32             ` Markus Mottl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20001209040315.D26367@miss.wu-wien.ac.at \
    --to=mottl@miss.wu-wien.ac.at \
    --cc=caml-list@inria.fr \
    --cc=gerd@gerd-stolpmann.de \
    --cc=miles@caddr.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).