[ios][mac] osm auth test fix

[biodranik]

The issue is that tests are blocked by the main thread.

[vng]

Did you check this session callbacks for possible synchronization or races?
IDK where this HTTP session is used now, but I remember that we perform file writing in downloader callback without sync.

[biodranik]

@vng the initial implementation was wrong. This whole downloader implementation should be refactored.
For iOS, we have a chunked downloader (not used now), and a synchronous one (used in sync calls to auth for example).
Chunked downloaded should use the same thread to write files and to modify internals. It may be a different thread, not the main one. But iOS API doesn't allow to explicitly specify threads.

Android HTTP still does not support HTTP/2 (and of course HTTP/3 too), so it may be a good time to refactor everything and get better download speed and less battery consumption.

[strump]

You can replace OsmOAuth::DevServerAuth() with OsmOAuth::ServerAuth() to have release or debug OSM host depending on DEBUG flag.

[strump]

Suggested change

	OsmOAuth auth = OsmOAuth::DevServerAuth();
	OsmOAuth auth = OsmOAuth::ServerAuth();

[biodranik]

@strump

Running osm_auth_tests.cpp::OSM_Auth_Login
FAILED
osm_auth_tests/osm_auth_tests.cpp:30 Unexpected exception at TEST(result = auth.AuthorizePassword(kValidOsmUser, kValidOsmPassword)) HTTP 401

Can you please help to debug what is wrong? We need some "test" credentials for the prod.

[strump]

Suggested change

	OsmOAuth auth = OsmOAuth::DevServerAuth();
	OsmOAuth auth = OsmOAuth::ServerAuth();

[vng]

It looks strange.

Is it possible to detect that we are already in main queue while performing dispatch_async(dispatch_get_main_queue()
I suppose that ObjC core should do it itself, something like coroutine concept.

[biodranik]

The main thread can be detected by NSThread.isMainThread, but it doesn't help here. The delegate is called from another thread. Old code posted a block to the main thread that was blocked in the test by dispatch_group_wait(group, DISPATCH_TIME_FOREVER); so the posted block was never executed.

[vng]

Ok then, if we already have taskInfoQueue for processing task infos, why we can't use it for running completionHandler always? Especially, because we use taskInfo.delegate and task itself to run handler.

Otherwise, assume calling dispatch taskInfo.delegate to dispatch_get_main_queue and calling removeTaskInfoForTask at the same time?

[biodranik]

Because Apple's dispatch queues are tricky. There is no guarantee that any queue except the main one will run on the same thread. The same queue can reuse different threads depending on their availability. And we have a lot of thread checkers in chunker downloader for example to make sure that its callbacks are always single-threaded.

Work submitted to dispatch queues executes on a pool of threads managed by the system. Except for the dispatch queue representing your app's main thread, the system makes no guarantees about which thread it uses to execute a task.

source

[biodranik]

This all mess should be rewritten properly using thread pools and lambdas )

[vng]

Ok, I'd put todo explaining isSyncHttpTest