On Mon, 4 Apr 2016 13:13:56 +0200
Mehturt <meht...@gmail.com> wrote:
> On Sat, Apr 2, 2016 at 4:53 PM, Mehturt <meht...@gmail.com> wrote:
> > On Sat, Apr 2, 2016 at 2:08 PM, Erik Massop <e...@ixsop.nl> wrote:
> >> In xmms2_current_id you're using $result->wait(). This is problematic,
> >> as wait() does not know what to do when a different result than $result
> >> comes in. You should use a callback also there.
>
> Can you please explain what is the problem here?
> Is it the synchronous call from asynchronous callback?
The problem is using wait() when there are outstanding async requests
(in this case the current_id broadcast). Wait() assumes that there is
only one response that could possibly come in, namely the one that it is
waiting for. If some else comes in, for instance a message saying that
the current_id changed, it will not be able to handle this.
I think you should be able to simulate this by sleeping for a while in
xmms2_current_id before calling medialib_get_info and then cycling
through songs rapidly. That way there should be new broadcast messages
lined up before you call medialib_get_info and its ->wait(). Hence
that ->wait() is certain to catch a message that it doesn't expect.
> Also, can you please point me out to the callback to use here?
Attached is another patch to tut6.pl, using a callback in the callback.
> It would be good if the .pod would mention this (synchronous and
> asynchronous alternative).
I agree with you that we should have much more explicit documentation
for sync vs async. However, given that I don't know perl - I wasn't
even able to write the loops in my_info and had to copy them from
tut5.pl - I'm not qualified to update the .pod.
Perhaps next to updating documentation, we should even store in the
connection whether it is being used synchronously or asynchronously so
that we can bail out on programming errors.
Cheers,
Erik / nesciens
>From 23b7210682f0452b6e06f8e3e53bb365bc60cfd3 Mon Sep 17 00:00:00 2001
From: Erik Massop <emas...@google.com>
Date: Sat, 9 Apr 2016 20:06:40 +0100
Subject: [PATCH 3/3] Do something interesting in the callback
---
perl/tut6.pl | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/perl/tut6.pl b/perl/tut6.pl
index 197cf3e..1b50dab 100644
--- a/perl/tut6.pl
+++ b/perl/tut6.pl
@@ -14,6 +14,19 @@ if (!$xmms->connect) {
exit 1;
}
+# This is used to display more information about a recently started song. Read
+# my_current_id and the main program first before returning here.
+
+sub my_info {
+ my ($propdict, $xc) = @_;
+ print "Got some metadata:\n";
+ while (my ($key, $values) = each %{ $propdict } ) {
+ while (my ($source, $val) = each %{ $values }) {
+ print " $key = $val ($source)\n";
+ }
+ }
+}
+
# We set this up as a callback for our current_id method. Read the main
# program first before returning here.
@@ -24,9 +37,15 @@ sub my_current_id {
# now extract it as normal. The second argument is our connection object
# which was passed in as the userdata.
- printf "Current id is %d\n", $value;
+ printf "Current id is %d. Requesting more information.\n", $value;
+
+ # Don't use ->wait() when you are using async requests, instead use
+ # callbacks for everything.
+
+ $xc->request( "medialib_get_info", $value, sub { my_info (@_, $xc) });
+
+ # We return 1 to signal that we want to stay subscribed to the broadcast.
- # We return 1 to signal that we want to stay subscribed to this broadcast.
return 1
}
--
2.1.4
--
_______________________________________________
Xmms2-devel mailing list
Xmms2-devel@lists.xmms2.org
https://lists.xmms2.org/cgi-bin/mailman/listinfo/xmms2-devel
