pcre, bifs, drivers and ports
Mon Jul 31 18:12:00 CEST 2006
On 31 Jul 2006, at 16:21, Ernie Makris wrote:
> Hi Sean
>> If you add this feature by hacking the otp release and adding bifs
>> would create all the long term issues of having a patched OTP
> Thats ok, I already patch my releases in order to fix a linux to_erl
> bug, and to allow the file driver to open /dev/urandom. The only
> pain is
> verifying the patch on a new release. But I know the code well enough
> that I can do it by hand each time.
Where I work we already have a quite heavily patched OTP release so I
know well the pain. For me the hassle of yet more patches would
almost certainly outweigh some small speed benefit..
>> You would unlikely to get adopters of any open source version you
>> released for much the same reason.
> I would still put it out there, if anyone wanted to use it, they would
> be welcome.
And I guess if they liked it enough they could add a driver option :-)
>> OTOH it is not too hard to create a linked in driver that could
>> alternatively be compiled as a port program. That way you give
>> users a
>> choice between speed of a driver (almost the same as a BIF), or fault
> I agree, but I also wanted to see how easy/difficult it would be to
> a few new bifs.
One more thing to think on - assuming that pcre itself is thread
safe, adding it as a driver would make multithreading quite
straightforward. Mats' comment about limiting length of REs does not
really cut it IMO. Blocking the whole emulator during a long regexp
calculation rarely sounds like the right solution for typical Erlang
But. It would be most fascinating to compare real world
1. BIF pcre
2. Driver pcre,
3. BIF pcre in SMT erlang.
More information about the erlang-questions