Re: [swift-corelibs-dev] DispatchQueue and Threads

> On Dec 22, 2017, at 10:59 AM, Pierre Habouzit via swift-corelibs-dev > wrote: > >> On Dec 21, 2017, at 10:57 AM, Geordie J via swift-corelibs-dev >> mailto:swift-corelibs-dev@swift.org>> wrote: >> >> Hi, >> >> We are having som

Re: [swift-corelibs-dev] DispatchQueue and Threads

> On Dec 21, 2017, at 10:57 AM, Geordie J via swift-corelibs-dev > wrote: > > Hi, > > We are having some issues with threading / dispatch queues this week. > Basically I’m wondering why the following “async” code has the output it does: > > print(Thread.isMainThread) // true > DispatchQueue.m

Re: [swift-corelibs-dev] Issue understanding libdispatch runloop poking

ber of files touched, but small in terms of scope). It'll also allow us to check that it doesn't regress other ports which is always a concern ;) > > On Oct 12, 2017, 9:08 PM -0300, Pierre Habouzit via swift-corelibs-dev > , wrote: >> oh and last, while working on FreeBS

Re: [swift-corelibs-dev] Issue understanding libdispatch runloop poking

is about to be removed. -Pierre > On Oct 12, 2017, at 4:56 PM, Pierre Habouzit via swift-corelibs-dev > wrote: > >> On Oct 12, 2017, at 4:52 PM, Pierre Habouzit via swift-corelibs-dev >> mailto:swift-corelibs-dev@swift.org>> wrote: >> >>> On Oct 12, 2017,

Re: [swift-corelibs-dev] Issue understanding libdispatch runloop poking

> On Oct 12, 2017, at 4:52 PM, Pierre Habouzit via swift-corelibs-dev > wrote: > >> On Oct 12, 2017, at 7:48 AM, Rogiel Sulzbach > <mailto:rog...@rogiel.com>> wrote: >> >> I am trying to get libdispatch working on FreeBSD but I am hitting a wall: I >&

Re: [swift-corelibs-dev] Issue understanding libdispatch runloop poking

> On Oct 12, 2017, at 7:48 AM, Rogiel Sulzbach wrote: > > I am trying to get libdispatch working on FreeBSD but I am hitting a wall: I > cannot get my head around how the runloop implementation dispatches a event > to the kqueue once a new job is submitted. So far I was able to get the > libra

Re: [swift-corelibs-dev] [swift-users] [swift-dev] New Swift Snapshots Available!

Yes, this is a known libkqueue issue because on linux watching a fd in epoll can only be done once, and EVFILT_READ/EVFILT_WRITE cause two registrations for the same fd, only one will stay. -Pierre > On Aug 26, 2016, at 5:43 PM, Jordan Rose via swift-corelibs-dev > wrote: > > > >> Begin fo

Re: [swift-corelibs-dev] Duplicate definition of va_list on Arm

> On Aug 19, 2016, at 10:35 PM, William Dillon wrote: > > Ok then. At this point I suppose I'm looking at maintaining a fork of > libdispatch. I can't think of any other solutions that make sense. That sounds like a bit of an extreme answer that won’t get you a lot of sympathy. The problem

Re: [swift-corelibs-dev] Duplicate definition of va_list on Arm

Dispatch/dispatch.h is a public header. So not really. -Pierre on his iPhone > On Aug 19, 2016, at 8:41 PM, William Dillon wrote: > > True enough. In that case, would be acceptable to match by architecture and > skip the import on arm? > >> On Aug 19, 2016, at 5:56 PM, Pierre Habouzit wrot

Re: [swift-corelibs-dev] Duplicate definition of va_list on Arm

the include was added to dispatch specifically to allow dispatch_io to build on intel so your patch I think would break Intel. I think the general problem is likely that glibc is not module friendly today. -Pierre > On Aug 19, 2016, at 11:53 AM, William Dillon via swift-corelibs-dev > wrote:

Re: [swift-corelibs-dev] Swift DispatchSource not working

the bug is known and will be fixed in Seed 3 (?). signal based sources are mapped to TYPE_READ by mistake in the overlay. Matt will confirm. -Pierre > On Jul 7, 2016, at 7:13 PM, Darren Mo via swift-corelibs-dev > wrote: > > I am trying to catch SIGWINCH (terminal window size changed) in Swi

Re: [swift-corelibs-dev] New GCD API change: DispatchWorkItems should be retained by their groups

> On Jul 7, 2016, at 11:03 AM, Pierre Habouzit wrote: > >> On Jul 7, 2016, at 10:01 AM, Karl via swift-corelibs-dev >> mailto:swift-corelibs-dev@swift.org>> wrote: >> >> Hi, >> >> I’d like to propose a change to the new GCD API; that DispatchWorkItems be >> retained by their groups (and in t

Re: [swift-corelibs-dev] New GCD API change: DispatchWorkItems should be retained by their groups

> On Jul 7, 2016, at 10:01 AM, Karl via swift-corelibs-dev > wrote: > > Hi, > > I’d like to propose a change to the new GCD API; that DispatchWorkItems be > retained by their groups (and in turn, for them to be retained by their > queues). This allows for whoever created the work item to crea

Re: [swift-corelibs-dev] Defining _GNU_SOURCE for module-map-included headers

> On Dec 21, 2015, at 11:00 AM, Jordan Rose wrote: > > >> On Dec 21, 2015, at 10:57 , Pierre Habouzit > > wrote: >> >>> On Dec 21, 2015, at 9:34 AM, Jordan Rose via swift-corelibs-dev >>> mailto:swift-corelibs-dev@swift.org>> wrote: >>> >>> Hm. If this is the right

Re: [swift-corelibs-dev] Defining _GNU_SOURCE for module-map-included headers

> On Dec 21, 2015, at 9:34 AM, Jordan Rose via swift-corelibs-dev > wrote: > > Hm. If this is the right setting to set on everybody's system, we could add > it as part of Clang initialization (for the Clang inside Swift). Otherwise, > you can use "-Xcc" to pass extra flags to Clang, in this ca

Re: [swift-corelibs-dev] [swift-corelibs-libdispatch] Port transform and use libbsd (#13)

will do in headers. Everywhere else HAVE_MACH is used correctly as expected. -Pierre on his iPhone > On 19 déc. 2015, at 13:11, Chris Hanson via swift-corelibs-dev > wrote: > >> On Dec 14, 2015, at 8:12 PM, Pierre Habouzit via swift-corelibs-dev >> wrote: >> >

Re: [swift-corelibs-dev] Recommended posix_spawnattr_t for NSTask's implementation

FWIW Glibc implements posix_spawn on posix platforms in terms of {,v}fork + execve. So that means that SIGCHLD can be used. I don’t think linux has per-thread wd, since linux has had atcalls for a very long time, which makes this system interface not useful and only weird (pthread_{,f}chdir).

Re: [swift-corelibs-dev] Recommended posix_spawnattr_t for NSTask's implementation

-Pierre > On Dec 18, 2015, at 11:14 AM, Philippe Hausler via swift-corelibs-dev > wrote: > > I would definitely say that posix_spawn is the correct path to implement > this; that will keep pretty close to the way the one on darwin works; > > Couple of suggestions: > > posix_spawnattr_setsig

Re: [swift-corelibs-dev] libdispatch epoll port

libev model isn’t compatible with dispatch model, and retrofiting one on top of the other will put you in a world of hurt, and would diverge from the OS X port greatly, which we’d like to avoid. I originally thought you were replying to the thread about having the Runloop queues code in dispatc

Re: [swift-corelibs-dev] libdispatch epoll port

-Pierre > On Dec 17, 2015, at 1:35 PM, Pierre Habouzit wrote: > >> On Dec 17, 2015, at 12:40 PM, Tony Parker via swift-corelibs-dev >> wrote: >> >> Hi Dzianis, >> >>> On Dec 17, 2015, at 12:36 PM, Dzianis Fedarenka via swift-corelibs-dev >>> wrote: >>> > On Dec 10, 2015, at 12:42 AM,

Re: [swift-corelibs-dev] libdispatch epoll port

> On Dec 17, 2015, at 12:40 PM, Tony Parker via swift-corelibs-dev > wrote: > > Hi Dzianis, > >> On Dec 17, 2015, at 12:36 PM, Dzianis Fedarenka via swift-corelibs-dev >> wrote: >> On Dec 10, 2015, at 12:42 AM, Joakim Hassila via swift-corelibs-dev wrote: Hi, >

Re: [swift-corelibs-dev] Git history

git rebase -i is great and very well documented, with tons of blogs post about it all over the web. if you pick `s` as a memonic it will squash and let you edit the merged commit message. If the base commit message is already good, use `f` and it will “fixup” it which is a squash where the orig

Re: [swift-corelibs-dev] [swift-corelibs-libdispatch] Port transform and use libbsd (#13)

> […] > On a previous pull request, Daniel had requested we use #ifdef __APPLE__ > instead of #if HAVE_MACH. Not sure if that also applies to this pull request > too or if HAVE_MACH is ok to use in these files. Hi, I think this explanation is worth sharing and not leaving on an hidden review. T

Re: [swift-corelibs-dev] libdispatch build issue

-Pierre > On Dec 14, 2015, at 9:18 AM, Pierre Habouzit via swift-corelibs-dev > wrote: > > Cool, I’ll have a look later this week or when it gets more ready ;) > > btw, we got a pull request that seem good to me > (https://github.com/apple/swift-corelibs-libdispa

Re: [swift-corelibs-dev] libdispatch build issue

Cool, I’ll have a look later this week or when it gets more ready ;) btw, we got a pull request that seem good to me (https://github.com/apple/swift-corelibs-libdispatch/pull/13 ) but I don’t have the linux setup to check it’s good, w

Re: [swift-corelibs-dev] libdispatch build issue

I was talking about the *dispatch* run loop code. I'm not sure it's needed. The main queue is a different story. -Pierre on his iPhone > On 11 déc. 2015, at 11:28, Tony Parker via swift-corelibs-dev > wrote: > > >>> On Dec 11, 2015, at 11:25 AM, Pierre

Re: [swift-corelibs-dev] libdispatch build issue

> On Dec 11, 2015, at 9:02 AM, Philippe Hausler via swift-corelibs-dev > wrote: > > This is only tangentially related: but I was attempting to build dispatch as > well to start work on CFRunLoop and a few other dispatch bound features in > Foundation on linux. I was seeing similar failures as

Re: [swift-corelibs-dev] libdispatch build issue

> On Dec 11, 2015, at 8:19 AM, Dzianis Fedarenka via swift-corelibs-dev > wrote: > > >> 11 дек. 2015 г., в 18:36, Pierre Habouzit > > написал(а): >> >> The linux port is in progress, and even if it built, right now, it wouldn’t >> be functional. >> >> -Pierre >

Re: [swift-corelibs-dev] libdispatch build issue

Hi, > On Dec 11, 2015, at 12:17 AM, f-dz-f via swift-corelibs-dev > wrote: > > Hi! I’m unable to build on OS X 10.11 > > Using make: > > ../private/voucher_activity_private.h:493:10: fatal error: 'os/lock_private.h' > file not found > #include > ^ > > Using Xcode: > > /User

Re: [swift-corelibs-dev] libdispatch roadmap and api addition proposal

> On Dec 10, 2015, at 1:06 AM, Joakim Hassila via swift-corelibs-dev > wrote: > >> On 8 dec. 2015, at 17:07, Pierre Habouzit wrote: >> >> My point is, adding API to dispatch is not something we do lightly. I’m not >> keen on an interface that only works for base queues. Mac OS and iOS code >

Re: [swift-corelibs-dev] libdispatch roadmap and api addition proposal

> On Dec 8, 2015, at 9:05 AM, Daniel A. Steffen via swift-corelibs-dev > wrote: > >> >> On Dec 8, 2015, at 6:11, Joakim Hassila wrote: >> >> Hi Daniel, >> >> >>> On 7 dec. 2015, at 23:11, Daniel A. Steffen wrote: >>> >>> FWIW I’ve updated the macosforge svn repo trunk to match with github

Re: [swift-corelibs-dev] libdispatch roadmap and api addition proposal

-Pierre > On Dec 8, 2015, at 7:34 AM, Joakim Hassila via swift-corelibs-dev > wrote: > > Hi Pierre, > > Thanks for the good explanation, will try to respond inline below: > >> On 7 dec. 2015, at 23:10, Pierre Habouzit > > wrote: >> >> Hi Joakim, Kevin, >> >> [ F

Re: [swift-corelibs-dev] libdispatch roadmap and api addition proposal

> On Dec 8, 2015, at 6:11 AM, Joakim Hassila via swift-corelibs-dev > wrote: > > Hi Daniel, > > >> On 7 dec. 2015, at 23:11, Daniel A. Steffen wrote: >> >> FWIW I’ve updated the macosforge svn repo trunk to match with github >> swift-corelibs-libdispatch trunk (sans the PRs, excecpt for my

Re: [swift-corelibs-dev] [swift-evolution] Proposal: add `noescape` attribute to public API (particularly libdispatch)

> On Dec 5, 2015, at 1:44 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > One option was to use the API notes feature of the compiler to annotate these > APIs as part of the import into Swift. Another is to get the C headers > changed (on Darwin too) to add the attribute. We may want