So there's a lot to read before asking a *completely* educated question about Ethereum, but hopefully I'm not jumping the gun too much...
Because Ethereum has a Turing complete scripting language, you cannot necessarily know how many cycles a script will take to execute, but Ethereum charges a fee based on how many cycles (past 16) that it takes your script to execute, how are you handling that?
If the contract doesn't have enough funds to fully feed it, my understanding is that it will cease execution. After all, if you're a miner, why would you do work for no fee?
Well that really sucks, that means you have to significantly overpay if you can't predict the runtime of your contract (which is a fact of turing completeness, though it's possible to write programs which have a deterministic run-length, what's the point of having a turing complete scripting language in that case?)
Then again it'd also suck to have an address drained of funds because of an accidental infinite loop in one of your scripts (though I hope you're not "testing live"!).
My point is there are multiple ways to handle this, all of them seem to suck in multiple ways, so I'm wondering what the devs are doing.
Fees - Ethereum contracts will regulate its Turing-complete functionality and prevent abusive transactions such as memory hogs and infinite loop scripts by instituting a transaction fee for each computational step of script execution. More expensive operations, such as storage accesses and cryptographic operations, will have higher fees, and there will also be a fee for every item of storage that a contract fills up. To encourage contracts to clean up after themselves, if a contract reduces the amount of storage that it uses a negative fee will be charged; in fact, there is a special SUICIDE opcode to clear a contract and send all funds and the hefty negative fee back to its creator.