All registered callbacks are removed once UnregisterCallbackForPinValueChangedEvent is called
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 30/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- csharp, linux, raspberry-pi
- Domain
- embedded-iot
Research direction
Start in the Raspberry Pi 3 Linux driver's RemoveCallbackForPinValueChangedEvent, where ClosePin is now called unconditionally, then compare it with LibGpiodV2Driver.ClosePin and the _eventObserver.HasSubscriptionsFor check that keeps the line open. Done when removing one of two callbacks on the same pin keeps the other receiving events and a second unregister no longer throws. The fix needs a real Raspberry Pi or a hardware-in-the-loop test to confirm.
Written by the indexing model from the issue text.
Description
I tested this PR on a Raspberry Pi 3 B+ with libgpiod v2 (Debian 13, libgpiod 2.2.1), and it also fixes #2614: a second RegisterCallbackForPinValueChangedEvent, UnregisterCallbackForPinValueChangedEvent and WaitForEvent no longer throw Device or resource busy. Registering, unregistering and registering a callback again works, and so does WaitForEvent (twice in a row, and before registering a callback).
One case still fails: two callbacks on the same pin. After one of them is unregistered, the other one gets no more events, and unregistering it throws InvalidOperationException: Pin 8 is not in use for callbacks.
controller.OpenPin(Pin, PinMode.Input);
controller.RegisterCallbackForPinValueChangedEvent(Pin, PinEventTypes.Rising | PinEventTypes.Falling, OnChange);
controller.RegisterCallbackForPinValueChangedEvent(Pin, PinEventTypes.Rising, OnChange2);
controller.UnregisterCallbackForPinValueChangedEvent(Pin, OnChange2); // OnChange gets no more events
controller.UnregisterCallbackForPinValueChangedEvent(Pin, OnChange); // InvalidOperationException
GPIO 8 had nothing connected, and the edges came from switching its internal pull-up and pull-down with pinctrl set 8 pu / pd (4 edges after each step):
| After | OnChange (rising and falling) |
OnChange2 (rising) |
|---|---|---|
Registering OnChange |
4 of 4 | — |
Registering OnChange2 |
4 of 4 | 2 of 2 |
Unregistering OnChange2 |
0 of 4 | — |
The cause seems to be that RaspberryPi3LinuxDriver.RemoveCallbackForPinValueChangedEvent now always calls _interruptDriver.ClosePin(pinNumber) and sets InUseByInterruptDriver = false. LibGpiodV2Driver.ClosePin disposes the line request and removes all the subscriptions of the line, although LibGpiodV2Driver.RemoveCallbackForPinValueChangedEvent already keeps the line while other callbacks remain (_eventObserver.HasSubscriptionsFor(offset)). Maybe the pin should be closed in the interrupt driver only when its last callback is removed.
Tested at a2740357, built on Windows with .NET SDK 10.0.401 (linux-arm64). With System.Device.Gpio 4.2.0, the same program fails as described in #2614.
Originally posted by @Kash0321 in https://github.com/dotnet/iot/issues/2610#issuecomment-5973268665
- Dominant language
- C#
- Stars
- 2.4k
- Forks
- 630
- Avg merge
- 6d 19h
- Merged PRs (30d)
- 11
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from dotnet/iot
-
LibGpiodV2EventObserver never disposes edge events: one finalizable SafeHandle per edge causes multi-ms gen0 GC pausesPossibly taken @krwq claimed this 5 days ago. Openuntriaged
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
dotnet/iot#2626 · 1 comment · 1 reaction · 2 assignees ·
Maintainers usually reply within 1 day
-
GpioController.QueryComponentInformation() throws NotSupportedException with RaspberryPi3DriverOpenuntriaged
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
api-suggestion untriaged
Difficulty 3/5 1-2 days Newbie friendliness 35/100
dotnet/iot#2620 · 3 comments ·
Maintainers usually reply within 1 day
-
untriaged
Difficulty 5/5 Over a week Newbie friendliness 35/100
Maintainers usually reply within 1 day
-
untriaged
Difficulty 3/5 1-2 days Newbie friendliness 76/100
dotnet/iot#2614 · 2 comments ·
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
Maintainers usually reply within 1 day
-
:watch: Not Triaged advanced-concepts/subsvc dotnet-csharp/svc
Difficulty 1/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day
-
enhancement no-stack-trace
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
greenshot/greenshot#1618 · 3 comments ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
microsoft/aspire.dev#1962 ·
Maintainers usually reply within 1 day
-
needs-area-label
Difficulty 2/5 1-3 hours Newbie friendliness 73/100
Maintainers usually reply within 1 day