From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: Christophe TROESTLER <Christophe.Troestler@umh.ac.be>
Cc: "O'Caml Mailing List" <caml-list@inria.fr>
Subject: Re: [Caml-list] Thread safe Str
Date: Mon, 10 Jan 2005 16:49:17 +0100 [thread overview]
Message-ID: <20050110154917.GA4582@yquem.inria.fr> (raw)
In-Reply-To: <20050109.203010.110660321.Christophe.Troestler@umh.ac.be>
> The new Str module not only made it LGPL but also very fast (100% more
> than Pcre in some cases). However it is still not thread safe -- and
> it is not possible given its interface. However, from a quick look,
> it seems to me that what is under the hood is almost thread safe.
You are correct: the regexp compiler (written in Caml) and the
execution engine (written in C) are thread-safe, it's only the API (in
Caml) that uses global state.
> So why not to write a new module (say Regexp) which would be thread
> safe and on top of which Str would be build?
That's a very good idea. My initial plan was to have two APIs, the
old Str for compatibility and a newer, better designed one for new
programs. Besides being thread-safe, the new API could also expose
the abstract syntax tree for regexps, allowing easier construction of
complex regexps by programs than can be done by working at the level
of the string representation of regexps. It's just that I never got
to design that new API :-(
> This would not be too much work, would it?
The implementation work should be quite small indeed, but don't
underestimate the work needed to design the API. API design is harder
than it seems... But if a few persons on this list want to team up to
design an API, that would be wonderful indeed. (A small group is
better than individual designers in that several pairs of eyes spot
inconsistencies better.)
- Xavier Leroy
next prev parent reply other threads:[~2005-01-10 15:49 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-09 19:30 Christophe TROESTLER
2005-01-09 20:57 ` [Caml-list] " Gerd Stolpmann
2005-01-10 9:57 ` Alex Baretta
2005-01-10 15:49 ` Xavier Leroy [this message]
2005-01-10 16:39 ` Richard Jones
2005-01-10 18:21 ` Eric C. Cooper
2005-01-10 20:25 ` Martin Jambon
2005-01-11 3:54 ` skaller
2005-01-11 7:03 ` Chris King
2005-01-11 8:06 ` skaller
2005-01-11 12:08 ` Gerd Stolpmann
2005-01-11 17:55 ` skaller
2005-01-11 20:30 ` Gerd Stolpmann
2005-01-12 7:42 ` skaller
[not found] ` <875c7e070501111007dc3e86d@mail.gmail.com>
[not found] ` <1105471138.2574.88.camel@pelican.wigram>
[not found] ` <875c7e07050111115618692184@mail.gmail.com>
2005-01-11 19:58 ` Chris King
2005-01-11 20:53 ` Martin Jambon
2005-01-12 7:59 ` skaller
2005-01-12 20:12 ` Martin Jambon
2005-01-11 6:41 ` Chris King
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=20050110154917.GA4582@yquem.inria.fr \
--to=xavier.leroy@inria.fr \
--cc=Christophe.Troestler@umh.ac.be \
--cc=caml-list@inria.fr \
/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