[Ur] interfacing with C or other languages - example system

[Adam Chlipala]

Marc Weber wrote:
>> optimistic SQL concurrency violation
>>      
> Maybe you can use pessimistic locking or such. Then the database is more
> likely to block rather than rollback (?)
>    

If you use pessimistic locking, you can still run into a deadlock, which 
is a problem when the surface language doesn't even expose locking to 
the programmer.  I would want to see an automatic restart in such cases.

>> No minimum heap setting yet.  This also wouldn't get around SQL
>> concurrency failures.
>>      
> You don't get around them anyway.

I don't understand this line.  I meant that a minimum heap setting 
wouldn't remove the need to do some explicit handling of concurrency 
failures, such that the most natural response seems to be a restart.

> I know that I can't prevent all
> reasons for restarting. But I can try to minimize them.
> Having a project option setting the "minimum heap size" seems to be
> a way to reduce some risks of restarting.
>    

Yes, this seems like a good, simple idea.  Would you mind opening a 
Mantis bug asking for this?

>> This would be extra complexity and a new performance hit with no
>> observable benefit for almost all cases, so I'm inclined against it.
>>      
> Ok. I don't see such a huge performance overhead. The overhead will be
> evaluating one cheap condition compared to restarting. But I agree that
> its not worth the effort.
>    

I didn't say "huge." :-)

> Anyway: Those are the use cases for Process.exec:
> run a php or ruby script and insert something into a database without
> having to code C.
>
> so you can do:
>
> ok<- Process.exec "verify-pay-confirm options"
>
> and put all the ugly caching into verify-pay-confirm and be done.
>    

Couldn't you just as easily write a C function that takes "options" as 
input and then always executes "verify-pay-confirm" with those options?  
That would make sure the Ur/Web layer can't introduce zany 
non-transactional behavior.