Problem when .close() is not called upon abnormal exit

[jfriend00]

I'm having a couple issues in trying to use this library for a program that uses gpio pins in output mode to control some external appliances:

1. If you call gpio.open() on a pin that is already exported to you, you get an error and the library does not finish the open operation. This is a problem because in an application that is repeatedly accessing the GPIO ins, I want to .open() the pin once and then use it during the application. If that application exits in any abnormal fashion, then the pin never gets .close() called on it. So, the next time you run the app and try to .open() the pin, the .open() fails. I'm not really sure how to work-around that issue as the .open() failure occurs in the quick2wire program so it's not easily accessible to change.
2. OK, I thought maybe I should make absolutely darn sure that no matter how my app exits that I close any pins I was using. But because the pi-gpio library using async IO and perhaps because it uses exec() to run the quick2wire program, try to close pins in all possible exit paths does not work reliably.
3. In any app exit scenario (normal or abnormal exit), I want to make sure all GPIO output pins I'm using get reset back to zero (turning off any appliances that are being controlled by the app). But, again because all file IO to the pins is async, there are problems guaranteeing that this finishes in some app exit scenarios. While I program mostly with async IO in node.js, there are some cases (particularly in abnormal exit scenarios) where async operations won't be allowed to complete before the process exits.

As for the first issue, I guess I want a .open() not to fail if the pin is already opened or for there to be some way in the error path to know that it is successfully opened.

As for the second issue, I'm not sure how to solve that except maybe to make a synchronous path (no async operations) that allows me to .close() all pins that were in use even in an exit path. Though, if the first issue is dealt with, then the second issue is not as necessary.

The third issue just seems like it needs a synchronous IO option such as gpio.writeSync().

Right now, since at least one of the issues is in the quick2wire code, I'm thinking that the only option may be to stop using that code and create a Javascript version of what it is doing that can be customized to solve this issue and merged directly into a fork of the pi-gpio library. I'd rather not be that disruptive to the direct you've done here, but I don't have any other ideas. Your thoughts?

[jfriend00]

One possible work-around to issue #1 is to just call gpio.close(pin) before I call gpio.open(pin) and just ignore any error that happens on the .close(). So, if the pin happens to be already exported, this will unexport it first so that the export in gpio.open() won't get an error and will allow it to finish. Certainly not a clean way to deal with this (feels quite a bit hackish), but without modifying the gpio-admin source (something I was trying to avoid doing), I don't have a different idea yet.

[tjanson]

I ran into the same problem. Wiring Pi’s gpio tool’s export function is idempotent, or at least doesn’t throw an error. I think it would be pretty simple to substitute gpio-admin with gpio – I’ll give it a try and report back.