Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[proposal] thread-safe variant of Str library #8091

Closed
vicuna opened this issue Apr 5, 2003 · 1 comment
Closed

[proposal] thread-safe variant of Str library #8091

vicuna opened this issue Apr 5, 2003 · 1 comment

Comments

@vicuna
Copy link

vicuna commented Apr 5, 2003

Original bug ID: 1625
Reporter: administrator
Status: closed (set by @mshinwell on 2016-12-07T15:24:22Z)
Resolution: won't fix
Priority: normal
Severity: feature
Category: otherlibs

Bug description

Full_Name: Yutaka OIWA
Version: 3.06+27
OS: Linux
Submission from: h219-110-060-091.catv01.itscom.jp (219.110.60.91)

How about to provide thread-safe variant of Str library?
It would be useful to have an MT-safe regexp library
in the standard distribution.

Previously, I wrote a thread-safe wrapper for Str library
using mutex, which is http://www.oiwa.jp/~yutaka/mtStr.mli
and http://www.oiwa.jp/~yutaka/mtStr.ml .

Recently I looked into the "to-be-3.07" CVS version of Str library,
and found that the engine written in C is almost thread-safe.
It seems that all global states are stored in Caml-level variables,
and only thread-unsafe portions of code are two static
temporary variables "re_group" and "re_register" in strstubs.c,
which can easily be moved to either stack or heap.

I think that interface for Str module should not be changed for
both compatibility and convenience. (But some replace-related functions
can be MT-safe without modification to their interface.)
So either providing a new module (like my MtStr), or adding another
set of functions for Str module might be desirable.

@vicuna
Copy link
Author

vicuna commented Dec 7, 2016

Comment author: @mshinwell

I think Str will be moved out of the compiler distribution in due course, so it seems most unlikely that it will be augmented with a thread-safe version prior to that time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant