pcre, bifs, drivers and ports

[Sean Hinde]

Hi Ernie,

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  
>> you
>> would create all the long term issues of having a patched OTP  
>> release.
>>
> 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
>> isolation.
>>
> I agree, but I also wanted to see how easy/difficult it would be to  
> add
> 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  
apps.

But. It would be most fascinating to compare real world  
characteristics of:

1. BIF pcre
2. Driver pcre,
3. BIF pcre in SMT erlang.

Sean