[PD] new disis_wiimote : undefined symbol: sys_flushtogui

[Ivica Ico Bukvic]

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