What is the status of async support in Xamarin?

[Kent Boogaart]

Hi,

Can anyone tell me the status of async/await support in Xamarin? I can't see it on the roadmap and am seeing blocking in the unit test runner. Here is a simple example of a test fixture that fails when using async/await. Note that this works perfectly in xUnit within Visual Studio (obviously using Win32 SQLite):

namespace TradeQuote.UnitTests
{
    using System;
    using System.Threading;
    using System.Threading.Tasks;
    using NUnit.Framework;
    using SQLite.Net;
    using SQLite.Net.Async;
    using SQLite.Net.Platform.XamarinIOS;

    [TestFixture]
    public class ReproFixture
    {
        [Test]
        public void repro()
        {
            var connection = this.GetConnection();

            var waitHandle = new ManualResetEventSlim(false);

            // works
            //this.WorksAsync(connection).ContinueWith(_ => waitHandle.Set());

            // does not
            this.DoesNotWorkAsync(connection).ContinueWith(_ => waitHandle.Set());

            Assert.True(waitHandle.Wait(TimeSpan.FromSeconds(3)));
        }

        private Task<bool> WorksAsync(SQLiteAsyncConnection connection)
        {
            return connection.ExecuteAsync("create table if not exists \"something\"(\"id\" integer primary key not null ,\"name\" varchar(140) )").ContinueWith(x => x.Result == 1);
        }

        private async Task<bool> DoesNotWorkAsync(SQLiteAsyncConnection connection)
        {
            return await connection.ExecuteAsync("create table if not exists \"something\"(\"id\" integer primary key not null ,\"name\" varchar(140) )") == 1;
        }

        private SQLiteAsyncConnection GetConnection()
        {
            var platform = new SQLitePlatformIOS();
            var connectionString = new SQLiteConnectionString(":memory:");
            var connection = new SQLiteConnectionWithLock(platform, connectionString)
            {
                Trace = true
            };
            return new SQLiteAsyncConnection(() => connection);
        }
    }
} 

Thanks

[Charlie Poole]

Are you running one of the special nunitlite builds provided by
xamarin? If so, I believe that's equivalent to our 0.7 release. They
would need to upgrade to 1.0 (or even better to 3.0) in order to have
async support.

Hopefully, somebody from xamarin is on the list and can add more to
this. It would be great if we could work out some better coordination
of releases.

Charlie

> --
> You received this message because you are subscribed to the Google Groups
> "NUnitLite" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nunitlite+...@googlegroups.com.
> To post to this group, send email to nuni...@googlegroups.com.
> Visit this group at http://groups.google.com/group/nunitlite.
> For more options, visit https://groups.google.com/groups/opt_out.

[Kent Boogaart]

Thanks Charlie. I'm horribly confused though. A quick google for "nunitlite" leads me here, which states 0.9 as the latest release. The second google hit leads me here, which points me here, which points me here, which (finally?) points me here. The versioning on NUnit github seems to be out of sync with NUnit on NuGet (2.9.6 versus 2.6.3). I don't see the V3 you mentioned anywhere. I'm throwing my arms up in the air at this point, hoping you can shed some light.

I've just tried my test with the latest NUnitLite from NuGet (V1) and it fails with a NRE inside NUnitLite. It does, however, pass with the latest NUnit NuGet (V2.6.3).

Can you please confirm which version (and from where) the Xamarin test runner should be aspiring to use?

Thanks,

Kent

[Charlie Poole]

Hi Kent,

Wow! That is confusing. I'll go back and clean up the links so you can
at least get to the last stop in a single jump.

NUnit and NUnitLite were once separate projects. NUnit gave birth to
NUnitLite, then NUnitLite influenced NUnit, etc. The last releases of
that old era were NUnit 2.6.3 and NUnitLite 1.0.

Future releases of NUnitLite will be built from a common source code
base along with NUnit. We call that NUnit 3.0. Up to now, we are still
pre-alpha and we are using the 2.9.x series to represent "almost 3.0"
The last binary release was NUnit 2.9.6 and the current source code is
on GitHub in the nunit.framework project.

As far as your question... I'm not sure. When you talk about the
"Xamarin Runner" what do you mean? Is it the NUnit addin for
MonoDevelop? That uses whatever version of NUnit (not NUnitLite) the
Xamarin guys last imported. AFAIK, you can't change the version, but I
could be wrong there.

OTOH, if you are developing for the IPad or IPhone, the Xamarin guys
have a special build of NUnitLite that works with that platform. They
have another special build that works with Android. You may need to
ask them for more info about it. If you find out more from another
source, I hope you'll post it here!

Charlie

[Kent Boogaart]

Thanks Charlie.

OK, so the situation is rather confused and it's not exactly obvious who the right people are to loop in on this. Plus, my time is limited. Therefore, I just grabbed the Touch.Unit code and hacked it to properly support async all the way from AsyncTaskInvocationRegion up to and including the UI. Now my tests run just fine.

Of course, I'll keep an eye out for updates and hope to remove my hacked version of the code later.

Cheers,

Kent

[Kent Boogaart]

Charlie, I meant to ask if NUnit 3 will be switching to a proper async model using TPL? I had a look at the latest code from github and it appears to still be blocking on the `Task`, which is going to cause deadlocking issues. IMHO, that would be a fundamental design flaw - one cannot expect certain async tests to work when the test thread blocks because async continuations may need to continue on that blocked thread. Of course, the difficulty is that you're trying to support platforms without the TPL so things could get messy.

Cheers,

Kent

[Charlie Poole]

Actually, NUnit async support (that is, for the async keyword) only
exists in .NET 4.5, so we could use TPL. We plan to extend it down to
4.0, which is also not a problem.

In general, wherever we do something on multiple platforms, we try to
use the highest level implementation that will work on all of them,
rather than doing alternative implementations for each platform.
Alternative implementations make it really hard to track when bugs
arise. But if we only do something in 4.0 plus, then it's not a
problem.

I have noticed some occasional locking when I run all my different
build flavors (9 of them) in separate processes, with each one using
three different threads in the framework. I haven't tracked it down
yet.

Can you point to the code on GitHub that concerns you?

Alternatively, if you'd like to get involved in helping us design this
- or even in coding - please join us on the nunit-developer group and
start a thread!

Charlie

> For more options, visit https://groups.google.com/d/optout.