Omitted callback functions cause port not to close

[vanevery]

@tigoe reports that if client doesn't register callback for "close" and/or "error" when those happen the, port doesn't close.

It could either be a client side issue with the missing callback creating a condition where the close property isn't updated or a server side issue resulting from an error generated on the client side.

This should be tested/verified and corrected.

[vanevery]

@kaganjd would you mind checking into this?

[kaganjd]

@tigoe can you link to the sketch you're using? And are you running into this problem with p5.serialcontrol or when you're using the library on its own?

[tigoe]

Any sketch that doesn't include a handler for .on('close') will do it.

[kaganjd]

not sure if this addresses the problem but it does seem like routing for the 'close' method was missing. i've added it in this commit. still to do:

• after calling serial.close() in the sketch, serial.isConnected() still returns true
• check what's going with unregistered error callbacks

let me know if i'm missing anything!

[tigoe]

Does serial.close() get called when the sketch stops running automatically? Is there a way to do it? I’m not clear on what events get called when a sketch gets stopped, so I don’t know when I would fire the close() function. Can you clarify that? Tom

…

On Oct 24, 2017, at 12:46 AM, Jen Kagan ***@***.***> wrote: not sure if this addresses the problem but it does seem like routing for the 'close' method was missing. i've added it in this commit <kaganjd/p5.serialport@1647c23#diff-d6bc58cabc93fd7941ff290c20f3e8ecR129>. still to do: after calling serial.close() in the sketch, serial.isConnected() still returns true check what's going with unregistered error callbacks let me know if i'm missing anything! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#39 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXOn0i1BaQAaDkez0DDD4gfQarXFvQIks5svRdBgaJpZM4P3Fra>.

[vanevery]

Thanks for catching that @kaganjd The commit looks good.

Just to clarify, the routing for the method was there and that worked, it was missing the callback routing so clients wouldn't get notified when a close occurred.

@tigoe no, serial.close() doesn't automatically get called when a client disconnects or a sketch stops. That would mess with the multiuser/client server model. On the server/p5.serialcontrol side, yes, if that is stopped/restarted/reloaded, the close method is called.

[vanevery]

I am guessing that the reported issue is fixed by this commit. The port was actually closed but clients weren't notified. That should be fixed by this.

[tigoe]

Is there any event that occurs when a sketch is stopped (not just put into the background? Or should we start training people to put close() at the beginning of their sketches to clean up any past open sketches? I’m looking for a way that avoids restarting the seriialcontol app. Tom

…

On Oct 24, 2017, at 4:12 PM, Shawn Van Every ***@***.***> wrote: Thanks for catching that @kaganjd <https://github.com/kaganjd> The commit looks good. Just to clarify, the routing for the method was there and that worked, it was missing the callback routing so clients wouldn't get notified when a close occurred. @tigoe <https://github.com/tigoe> no, serial.close() doesn't automatically get called when a client disconnects or a sketch stops. That would mess with the multiuser/client server model. On the server/p5.serialcontrol side, yes, if that is stopped/restarted/reloaded, the close method is called. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#39 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXOnyu3oWhg8SN2_i8TB2NuSBAdOYesks5svfBNgaJpZM4P3Fra>.

[vanevery]

p5.js doesn't have anything that covers that. There are a variety of ways in pure JS in the browser but not super easy.

The server receives an event when the socket closes and it cleans up the list of clients. Also, if it is in fact the last client it does close the serial port but in use this never happens because the p5.serialcontrol frontend is a client itself.

The other mechanism is to push the "close" button the p5.serialcontrol interface.

I am unsure of what the expected behavior should be. Traditional serial and network applications act differently in this regard.

Perhaps if the p5.serialcontrol interface had an indication of the open port that would probably solve a majority of the issues by informing the user of the state?

[kaganjd]

i just dropped some UI sketches that might address some of these things over in p5-serial/p5.serialcontrol#11

@vanevery since you said the commit probably addresses the reported issue, what do y'all think of these next steps?

1. submit PR with the 'close' routing commit
2. close this issue
3. move UI conversation to p5.serialcontrol