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
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
