On 5/11/12 10:24 AM, Hans-Christoph Steiner wrote:
On May 10, 2012, at 1:45 PM, Ivica Ico Bukvic wrote:
Why do you think that this can only be done by exposing sys_flushtogui()? My guess is that this can be done using the current public API, but I'd to
know
more about the issue to make a concrete suggestion.
Indeed... To make any suggestions, like the one below, you would need to look at the external's behavior. In this case, connection is handled in the same thread as pd which means the thread freezes until wiimote connects. Because connection happens immediately after requesting the posting of a message "please press 1+2 buttons on a wiimote to connect" (which I would argue is rather important bit of information for a user), the message never reaches the gui because the thread freezes waiting on the Bluetooth stack to report that the connection has succeeded/failed. Flushtogui placed in between the post() call and the connect() call allows for the said message to be indeed displayed before the pairing takes place. If you can think of a better way to do this I'd certainly appreciate suggestions.
It sounds to me like the issue in the thread programming. Using threads in Pd externals is tricky since the thread has to sync up with Pd, which uses an entirely different kind of scheduling than threads.
Yes, and that's in part why options are rather limited as to how to handle this issue.
Why not handle the connect in the other thread? Or even better, maybe there is a non-blocking way to do it where [wiimote] registers a callback, then sends the connect message, and carries on normally.. Then once the wiimote finished connecting, cwiid calls the callback in Pd, and Pd registers the wiimote as connected.
.hc
That would be a lot harder to pull off as the current design is where the secondary thread only receives cues to do things, it does not send anything back. In the design you suggested (and which BTW I already considered before) the secondary thread would also have to return something to the main thread (namely pointer to the wiimote instance as cwiid instantiates wiimote struct and supporting variables at connection and destroys them when the wiimote disconnects). This means either having another entirely independent thread that exits as soon as the wiimote connects returning the object or having some seriously ugly code that tries to notify main thread when the wiimote has been fully instantiated. Between that and exposing one call (which is AFAIK benign to use in this context), I'd call with the exposing the call.
Ico