Wednesday, April 7, 2010

in-memory db.....or should I say in-ram

Yes, yes its true, when I first saw Issue 10 I was like "pfft that is easy just set a default file name in the options parser."

Anyways long story short, I miss understood the whole in-memory thing, yea hindsight is 20/20, I have now implemented the proper fix which ended up being just as easy, thanks to sqlite3.

Though I won't lie I made it out to be a lot harder then it was and spent a few hours doing erroneous things. In the end though I learnt lots about the server side of pony-build, so win-win.

STOP RIGHT THERE!......subprocesses

So I spent a majority of my pony-build time during the month of February working on subprocess timeouts. Cause face it, we don't want those pesky little things running forever hogging up our precious system resources. Visit this link for some visuals on the following information breakdown.

  • First we need to grab the time the subprocess tarted running.
  • Then we use subprocess to run any commands that where passed.
  • We poll the process, grab the current time, then test to see if the time that has elapsed since start is greater then the specified timeout.
  • If it is greater then the timeout we go ahead and start the kill process, windows first, since my Windows machine is down I am unable to test this code (bad!). The unix code however has been tested and works.
  • In unix we kill the process then wait to make sure its doen before we carry on because if we don't it sorta defeats the purpose.
The theory behind the ImportError is if it is not running on windows machine we will get and ImportError exception and we can bounce down to the Unix code. During my research, as we can all guess, windows is a bit fussy and more complicated when it comes to OS level stuff. Once I get my Windows box back up or I can wrangle a work PC in for the job I will update with the results.