Al cumplir con los protocolos o anular los métodos de la superclase, es posible que no pueda cambiar un método para que sea async , pero es posible que desee llamar a algún código async . Por ejemplo, mientras estoy reescribiendo un programa para escribirlo en términos de la nueva concurrencia estructurada de Swift, me gustaría llamar a un código de configuración async al comienzo de mi conjunto de pruebas anulando la class func setUp() definida en XCTestCase . Quiero que mi código de configuración se complete antes de que se ejecute cualquiera de las pruebas, por lo que usar Task.detached o async { ... } no es apropiado.

Inicialmente, escribí una solución como esta:

 final class MyTests: XCTestCase { override class func setUp() { super.setUp() unsafeWaitFor { try! await doSomeSetup() } } } func unsafeWaitFor(_ f: @escaping () async -> ()) { let sema = DispatchSemaphore(value: 0) async { await f() sema.signal() } sema.wait() }

Esto parece funcionar bastante bien. Sin embargo, en Concurrencia de Swift: Detrás de escena , el ingeniero de tiempo de ejecución Rokhini Prabhu afirma que

Las primitivas como los semáforos y las variables de condición no son seguras para usar con la concurrencia de Swift. Esto se debe a que ocultan la información de dependencia del tiempo de ejecución de Swift, pero introducen una dependencia en la ejecución de su código... Esto viola el contrato de tiempo de ejecución de avance de subprocesos.

También incluye un fragmento de código de un patrón de código tan inseguro

 func updateDatabase(_ asyncUpdateDatabase: @Sendable @escaping () async -> Void) { let semaphore = DispatchSemaphore(value: 0) async { await asyncUpdateDatabase() semaphore.signal() } semaphore.wait() }

que es notablemente el patrón exacto que se me ocurrió (me parece muy divertido que el código que se me ocurrió es exactamente el cambio de nombre de módulo de código incorrecto canónico).

Desafortunadamente, no he podido encontrar ninguna otra forma de esperar a que se complete el código asíncrono desde una función síncrona. Además, no he encontrado ninguna forma de obtener el valor de retorno de una función asíncrona en una función síncrona. Las únicas soluciones que he podido encontrar para esto en Internet parecen tan incorrectas como la mía, por ejemplo, este artículo de The Swift Dev dice que

Para llamar a un método asíncrono dentro de un método de sincronización, debe usar la nueva función de separación y aún debe esperar a que las funciones asíncronas se completen usando las API de envío.

que creo que es incorrecto o al menos inseguro.

¿Cuál es una forma correcta y segura de esperar a que una función async de una función síncrona funcione con los requisitos de protocolo o clase síncrona existentes, no específicos de las pruebas o XCTest? Alternativamente, ¿dónde puedo encontrar documentación que explique las interacciones entre async / await en Swift y las primitivas de sincronización existentes como DispatchSemaphore ? ¿Nunca son seguros o puedo usarlos en circunstancias especiales?

Actualizar:

Según la respuesta de @TallChuck, que notó que setUp() siempre se ejecuta en el hilo principal, descubrí que puedo bloquear intencionalmente mi programa llamando a cualquier función @MainActor . Esta es una excelente evidencia de que mi solución debe ser reemplazada lo antes posible.

Explícitamente, aquí hay una prueba que se cuelga.

 import XCTest @testable import Test final class TestTests: XCTestCase { func testExample() throws {} override class func setUp() { super.setUp() unsafeWaitFor { try! await doSomeSetup() } } } func doSomeSetup() async throws { print("Starting setup...") await doSomeSubWork() print("Finished setup!") } @MainActor func doSomeSubWork() { print("Doing work...") } func unsafeWaitFor(_ f: @escaping () async -> ()) { let sema = DispatchSemaphore(value: 0) async { await f() sema.signal() } sema.wait() }

Sin embargo, no se cuelga si @MainActor está comentado. Uno de mis temores es que si alguna vez llamo al código de la biblioteca (de Apple o de otro tipo), no hay forma de saber si eventualmente llamará a una función @MainActor , incluso si la función en sí no está marcada como @MainActor .

Mi segundo temor es que incluso si no hay @MainActor , todavía no sé si tengo la garantía de que esto es seguro. En mi computadora, esto cuelga.

 import XCTest @testable import Test final class TestTests: XCTestCase { func testExample() throws {} override class func setUp() { super.setUp() unsafeWaitFor { unsafeWaitFor { unsafeWaitFor { unsafeWaitFor { unsafeWaitFor { unsafeWaitFor { print("Hello") } } } } } } } } func unsafeWaitFor(_ f: @escaping () async -> ()) { let sema = DispatchSemaphore(value: 0) async { await f() sema.signal() } sema.wait() }

Si esto no funciona para usted, intente agregar más unsafeWaitFor s. Mi VM de desarrollo tiene 5 núcleos, y esto es 6 unsafeWaitFor s. 5 funciona bien para mí. Esto es claramente diferente a GCD. Aquí hay un equivalente en GCD que no se cuelga en mi máquina.

 final class TestTests: XCTestCase { func testExample() throws {} override class func setUp() { super.setUp() safeWaitFor { callback in safeWaitFor { callback in safeWaitFor { callback in safeWaitFor { callback in safeWaitFor { callback in safeWaitFor { callback in print("Hello") callback() } callback() } callback() } callback() } callback() } callback() } } } func safeWaitFor(_ f: @escaping (() -> ()) -> ()) { let sema = DispatchSemaphore(value: 0) DispatchQueue(label: UUID().uuidString).async { f({ sema.signal() }) } sema.wait() }

Esto está bien porque GCD está feliz de generar más subprocesos que CPU tiene. Entonces, tal vez el consejo es "solo use tantos unsafeWaitFor s como CPU tenga", pero si ese es el caso, me gustaría ver en algún lugar que Apple lo haya explicado explícitamente. En un programa más complejo, ¿puedo estar realmente seguro de que mi código tiene acceso a todos los núcleos de la máquina, o es posible que alguna otra parte de mi programa esté usando los otros núcleos y, por lo tanto, el trabajo solicitado por unsafeWaitFor nunca estar programado?

Por supuesto, el ejemplo en mi pregunta es sobre pruebas, y en ese caso, es fácil decir "realmente no importa cuál sea el consejo: si funciona, funciona, y si no funciona, el la prueba falla y usted la arreglará", pero mi pregunta no se trata solo de las pruebas; eso fue solo un ejemplo

Con GCD, me he sentido confiado en mi capacidad para sincronizar código asíncrono con semáforos (en mis propias DispatchQueue que controlo, y no en el subproceso principal) sin agotar el total de subprocesos disponibles. Me gustaría poder sincronizar el código async desde una función síncrona con async / await en Swift 5.5.

Si algo como esto no es posible, también aceptaría la documentación de Apple explicando exactamente en qué casos puedo usar con seguridad unsafeWaitFor o técnicas de sincronización similares.