uber / swift-concurrency Goto Github PK

If an error is thrown while some tasks are still waiting to be executed, dispatch_semaphore_dispose can cause a crash with an error EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) .

(From stackotter/delta-client#113)

When compiling the repository mentioned above, when it reaches a subdependency of swift-concurrency, it reaches this error:

Working copy of https://github.com/apple/swift-log resolved at 1.4.2
'swift-nio-zlib-support': warning: ignoring declared target(s) 'swift-nio-zlib-support' in the system package
Building for production...
In file included from ./delta-client/.build/checkouts/JJLISO8601DateFormatter/Sources/JJLISO8601DateFormatter/JJLISO8601DateFormatter.m:3:
./delta-client/.build/checkouts/JJLISO8601DateFormatter/Sources/JJLISO8601DateFormatter/include/JJLISO8601DateFormatter.h:3:9: fatal error: 'Foundation/Foundation.h' file not found
#import <Foundation/Foundation.h>
        ^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ./delta-client/.build/checkouts/swift-concurrency/Sources/ObjCBridges/AtomicBridges.m:17:
./delta-client/.build/checkouts/swift-concurrency/Sources/ObjCBridges/include/AtomicBridges.h:17:9: fatal error: 'Foundation/Foundation.h' file not found
#import <Foundation/Foundation.h>
        ^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ./delta-client/.build/checkouts/JJLISO8601DateFormatter/Sources/JJLISO8601DateFormatter/JJLInternal.c:3:
1: error: unknown type name 'ssize_t'; did you mean 'size_t'?
ssize_t jjl_saferead(int fd, void *buffer, size_t nbytes);
^~~~~~~
size_t
'size_t' declared here
typedef __SIZE_TYPE__ size_t;
                      ^



1 error generated.
1 error generated.
[4/14] Compiling c-atomics.c

With a concurrency limited ConcurrentSequenceExecutor, if a task throws an error during execution, the entire execution can halt.

Hello,
First, thank you for this library. It is very useful.

But, I have build problem (errors) since version 0.6.5, using Carthage. The latest version which works to me is 0.6.4, but unfortunately I cannot update to any version after, including latest 0.7.1, because of build problem using Carthage.

I see some very strange hardcoded paths in build logs:
/Users/yiw/Uber/GitHub/swift-concurrency

Please check and thanks a lot!

Here are the logs attached for 0.6.5, 0.7.0 and 0.7.1. As said, 0.6.4 builds correctly.
0.6.4.log
0.6.5.log
0.7.0.log
0.7.1.log

A better installation guide should be there.

This probably should be a wiki page or something other than an issues, but just wanted to cover some details I discovered after reviewing and merging : 1880d77

The reason for having a loop is due to "spurious wakeup"s. While it appeared to be almost a bug in the NSCondition API, it seems that this, while somewhat counterintuitive, is by design.

1. We don't have the source to NSCondition, but it seems that it's probably just a slim wrapper around pthread_cond_wait and pthread_cond_timedwait
2. This issue exists at the pthread layer, so it's not really NSConditions fault
3. Spurious wakeups are mentioned clearly in the man pages : http://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_cond_wait.html
4. While it seems to be a strange API choice, it seems that someone balanced performance with was-of-use of the API and consciously chose better performance over a simpler API. Wiki page about it : https://en.wikipedia.org/wiki/Spurious_wakeup
5. Quote from that page (and elsewhere) :

This means that when you wait on a condition variable, the wait may (occasionally) return when no thread specifically broadcast or signaled that condition variable. Spurious wakeups may sound strange, but on some multiprocessor systems, making condition wakeup completely predictable might substantially slow all condition variable operations. The race conditions that cause spurious wakeups should be considered rare.