[swift-corelibs-dev] Git history

[Tom Jowett via swift-corelibs-dev]

Hi everyone,

I'm wondering if there's a way I can help to keep the commit structure of
the repo a bit tidier?  I can see the guideline being provided
on CONTRIBUTING.md however the current commit history could be a little
easier to follow for the average viewer (eb06d19 and b4f6e2b were duplicate
commits, e.g) and it seems the rebase before PR element of that guideline
could be better followed.

Perhaps a link in CONTRIBUTING.md to a walkthrough on how to squash and
rebase commits (including adding tests appropriately for bisect) could be
helpful?  Happy to put one together in the context of this project if you
think so.  Also interested in any other suggestions you might have for how
this could be remedied.

Cheers,
Tom
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Git history

[James Campbell via swift-corelibs-dev]

Help on rebasing would be great. I use git all the time but I still
struggle to squash my commits as I usually don't do it.

On Thu, Dec 17, 2015 at 9:25 AM, Tom Jowett via swift-corelibs-dev <
swift-corelibs-dev@swift.org> wrote:

> Hi everyone,
>
> I'm wondering if there's a way I can help to keep the commit structure of
> the repo a bit tidier?  I can see the guideline being provided
> on CONTRIBUTING.md however the current commit history could be a little
> easier to follow for the average viewer (eb06d19 and b4f6e2b were duplicate
> commits, e.g) and it seems the rebase before PR element of that guideline
> could be better followed.
>
> Perhaps a link in CONTRIBUTING.md to a walkthrough on how to squash and
> rebase commits (including adding tests appropriately for bisect) could be
> helpful?  Happy to put one together in the context of this project if you
> think so.  Also interested in any other suggestions you might have for how
> this could be remedied.
>
> Cheers,
> Tom
>
>
>
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>
>


-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Git history

[Pierre Habouzit via swift-corelibs-dev]

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 original commit message is kept and the 
other one discarded.

-Pierre

> On Dec 17, 2015, at 2:07 AM, James Campbell via swift-corelibs-dev 
>  wrote:
> 
> Help on rebasing would be great. I use git all the time but I still struggle 
> to squash my commits as I usually don't do it. 
> 
> On Thu, Dec 17, 2015 at 9:25 AM, Tom Jowett via swift-corelibs-dev 
> mailto:swift-corelibs-dev@swift.org>> wrote:
> Hi everyone,
> 
> I'm wondering if there's a way I can help to keep the commit structure of the 
> repo a bit tidier?  I can see the guideline being provided on CONTRIBUTING.md 
> however the current commit history could be a little easier to follow for the 
> average viewer (eb06d19 and b4f6e2b were duplicate commits, e.g) and it seems 
> the rebase before PR element of that guideline could be better followed.
> 
> Perhaps a link in CONTRIBUTING.md to a walkthrough on how to squash and 
> rebase commits (including adding tests appropriately for bisect) could be 
> helpful?  Happy to put one together in the context of this project if you 
> think so.  Also interested in any other suggestions you might have for how 
> this could be remedied.
> 
> Cheers,
> Tom
> 
> 
>  
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
> 
> 
> 
> 
> 
> -- 
>  Wizard
> ja...@supmenow.com 
> +44 7523 279 698
>  ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Git history

[Tony Parker via swift-corelibs-dev]

Hi Tom,

I’ve actually been thinking about this a lot over the past few days, but 
haven’t come to any real conclusion yet.

The way I’ve traditionally worked on Foundation is that each commit has more 
content, and each commit is (almost) always associated with a bug. This is 
basically the process I had in mind when I wrote the CONTRIBUTING document.

However, we’re at such an early stage in this project now that I don’t want to 
add a lot of overhead to PRs that contain basic functionality. I’m also 
grateful for all of the work that everyone is putting in, and don’t want to put 
off potential contributors with an overly pedantic policy. We’re trying as hard 
as we can to keep up with everything, but some PRs are sitting for some time 
before we can fully review them, which means they are inevitably out of date 
and have to be rebased.

I think that as more projects start to depend upon the library we will have to 
be much more cautious about how we accept changes, how they are tested, and how 
they are structured (e.g., for easier reverting).

I welcome additional thoughts on this topic.

Thanks,
- Tony

> On Dec 17, 2015, at 1:25 AM, Tom Jowett via swift-corelibs-dev 
>  wrote:
> 
> Hi everyone,
> 
> I'm wondering if there's a way I can help to keep the commit structure of the 
> repo a bit tidier?  I can see the guideline being provided on CONTRIBUTING.md 
> however the current commit history could be a little easier to follow for the 
> average viewer (eb06d19 and b4f6e2b were duplicate commits, e.g) and it seems 
> the rebase before PR element of that guideline could be better followed.
> 
> Perhaps a link in CONTRIBUTING.md to a walkthrough on how to squash and 
> rebase commits (including adding tests appropriately for bisect) could be 
> helpful?  Happy to put one together in the context of this project if you 
> think so.  Also interested in any other suggestions you might have for how 
> this could be remedied.
> 
> Cheers,
> Tom
> 
> 
>  ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-corelibs-dev] Starter bug: Run Foundation tests against OS X Foundation

[Tony Parker via swift-corelibs-dev]

Hi everyone,

I filed a bug here that would be a great way for someone to jump into 
contributing to swift-corelibs-foundation:

SR-276 

The basic idea is that we could really use a way to run our Swift test suite 
against the system (OS X) Foundation. This will help everyone to verify that 
the behavior of the library we are building is the same as OS X. If it’s not, 
then we know we have a bug to resolve in some way.

Let me know if you have any questions,
- Tony

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-corelibs-dev] Upcoming holiday schedule

[Tony Parker via swift-corelibs-dev]

Hello fellow contributors,

As you are aware, we are fast approaching the year-end holiday season. Here at 
Apple, many of us are taking some time off starting next week through the new 
year. As a result, it is likely that some pull requests will take more time 
than expected to review and merge. Even if some of us are on vacation, this is 
a great opportunity for anyone to jump in and help review PRs!

Thanks and happy new year,
- Tony

 
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Upcoming holiday schedule

[Brian Gesiak via swift-corelibs-dev]

Thanks for the head's up! Conversely, I imagine that for many people, holidays 
from work are precisely the time to contribute! :)
- Brian Gesiak






On Thu, Dec 17, 2015 at 9:03 AM -0800, "Tony Parker via swift-corelibs-dev" 
 wrote:










Hello fellow contributors,

As you are aware, we are fast approaching the year-end holiday season. Here at 
Apple, many of us are taking some time off starting next week through the new 
year. As a result, it is likely that some pull requests will take more time 
than expected to review and merge. Even if some of us are on vacation, this is 
a great opportunity for anyone to jump in and help review PRs!

Thanks and happy new year,
- Tony

 
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev





___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Upcoming holiday schedule

[Philippe Hausler via swift-corelibs-dev]

I will probably be around a bit more than Tony over the break; I will try to 
keep up with the pull requests.

There are a few things that I think will speed up the process so that we can 
keep things running well:

Discrete commits that implement a specific thing; reviewing two different spots 
sometimes is a bit hard to follow it all.
Review feedback from the community helps a ton
Rebasing commits from master so that there are no merge conflicts makes my job 
easier.
Unit tests are awesome!

These are rules of thumb that actually can apply easily beyond the break.

> On Dec 17, 2015, at 9:11 AM, Tony Parker via swift-corelibs-dev 
>  wrote:
> 
> Indeed! I hope the mismatch doesn’t cause us to fall too far behind. ;)
> 
> - Tony
> 
>> On Dec 17, 2015, at 9:10 AM, Brian Gesiak > > wrote:
>> 
>> Thanks for the head's up! Conversely, I imagine that for many people, 
>> holidays from work are precisely the time to contribute! :)
>> 
>> - Brian Gesiak
>> 
>> 
>> 
>> 
>> 
>> On Thu, Dec 17, 2015 at 9:03 AM -0800, "Tony Parker via swift-corelibs-dev" 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Hello fellow contributors,
>> 
>> As you are aware, we are fast approaching the year-end holiday season. Here 
>> at Apple, many of us are taking some time off starting next week through the 
>> new year. As a result, it is likely that some pull requests will take more 
>> time than expected to review and merge. Even if some of us are on vacation, 
>> this is a great opportunity for anyone to jump in and help review PRs!
>> 
>> Thanks and happy new year,
>> - Tony
>> 
>>  
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>> 
> 
>  ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
> 
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Upcoming holiday schedule

[Tony Parker via swift-corelibs-dev]

Indeed! I hope the mismatch doesn’t cause us to fall too far behind. ;)

- Tony

> On Dec 17, 2015, at 9:10 AM, Brian Gesiak  wrote:
> 
> Thanks for the head's up! Conversely, I imagine that for many people, 
> holidays from work are precisely the time to contribute! :)
> 
> - Brian Gesiak
> 
> 
> 
> 
> 
> On Thu, Dec 17, 2015 at 9:03 AM -0800, "Tony Parker via swift-corelibs-dev" 
> mailto:swift-corelibs-dev@swift.org>> wrote:
> 
> Hello fellow contributors,
> 
> As you are aware, we are fast approaching the year-end holiday season. Here 
> at Apple, many of us are taking some time off starting next week through the 
> new year. As a result, it is likely that some pull requests will take more 
> time than expected to review and merge. Even if some of us are on vacation, 
> this is a great opportunity for anyone to jump in and help review PRs!
> 
> Thanks and happy new year,
> - Tony
> 
>  
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-corelibs-dev] Proposal: Make NSTask's standardInput/standardOutput/standardError properties type-safe

[Dan Stenmark via swift-corelibs-dev]

This is my first proposal to swift-corelibs, so I’m not sure how much 
flexibility we have in terms of deviating from the darwin’s original Foundation 
definitions.  That said, it’s always seemed a little screwy to me that NSTask's 
standardInput/standardOutput/standardError properties sacrifice any semblance 
of compile-time type safety by accepting id/AnyObject (which, at run time, must 
be either NSPipe or NSFileHandle, else it blows up).  If allowed, I’d like to 
take the opportunity to modernize this in the open source version of Foundation.

public class NSTask : NSObject {

...

public enum IOType {

case FileHandle(NSFileHandle)
case Pipe(NSPipe)
}

public var standardInput: NSTask.IOType?
public var standardOutput: NSTask.IOType?
public var standardError: NSTask.IOType?

...

   
}

Dan___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Proposal: Make NSTask's standardInput/standardOutput/standardError properties type-safe

[Tony Parker via swift-corelibs-dev]

Hi Dan,

Thank you for your proposal. This is the right place to start discussion of it. 
If we want to do this then we would have to make changes in both Darwin and 
open source versions, to maintain source compatibility.

Out of curiosity, why propose an enum instead of an additional set of typed 
properties? Looking at the implementation of NSTask, it sure seems like we only 
expect either a file handle or pipe. I’m not sure if we would ever add another.

- Tony

> On Dec 17, 2015, at 11:34 AM, Dan Stenmark via swift-corelibs-dev 
>  wrote:
> 
> This is my first proposal to swift-corelibs, so I’m not sure how much 
> flexibility we have in terms of deviating from the darwin’s original 
> Foundation definitions.  That said, it’s always seemed a little screwy to me 
> that NSTask's standardInput/standardOutput/standardError properties sacrifice 
> any semblance of compile-time type safety by accepting id/AnyObject (which, 
> at run time, must be either NSPipe or NSFileHandle, else it blows up).  If 
> allowed, I’d like to take the opportunity to modernize this in the open 
> source version of Foundation.
> 
> public class NSTask : NSObject {
> 
> ...
> 
> public enum IOType {
> 
> case FileHandle(NSFileHandle)
> case Pipe(NSPipe)
> }
> 
> public var standardInput: NSTask.IOType?
> public var standardOutput: NSTask.IOType?
> public var standardError: NSTask.IOType?
> 
> ...
> 
>
> }
> 
> Dan
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-corelibs-dev] libdispatch epoll port

[Dzianis Fedarenka via swift-corelibs-dev]

>> On Dec 10, 2015, at 12:42 AM, Joakim Hassila via swift-corelibs-dev 
>>  wrote: 
>>  
>> Hi, 
>>  
>>> On 8 dec. 2015, at 16:56, Pierre Habouzit  wrote: 
>>>  
>>> FWIW, this is my personal, let’s call it enlightened, opinion, based on my 
>>> knowledge of dispatch and my past extensive system programming experience 
>>> with Linux before I joined Apple. 
>>>  
>>> I think that long term, the best way to maintain a Linux libdispatch port 
>>> is to go away from the libkqueue that tries to emulate kqueue fully, where 
>>> dispatch only needs a small subset of the surface of kqueue. Given how 
>>> source.c is written today, this is not a very small undertaking, but 
>>> eventually dispatch source map to epoll_ctl(EPOLLONESHOT) very very well. 
>> 
>> That makes sense, could simplify the implementation (and keep thing 
>> cleaner). Then the follow up question is of course how to split/manage 
>> source.c (as Daniel pointed out there is the merging issue). 
> we can decide when/if someone tries to tackle it. I humbly recognize that I 
> have no great idea of how to do so.

I have some experience in event multiplexing programming for linux. So it looks 
like interesting project for me. There is some conceptual questions which I 
think should be discussed:

1) Obviously, kqueue and epoll have a little different semantics. For example: 
in linux timers, signals and socket can be presented as file descriptor and 
processed uniformly. Is there any chance that community will agree to develop 
separate API for linux?
2) Does anyone have long term vision about how to inject platform specific code 
into current implementation of dispatch_source? As far as I’ve read the source 
it’s heavily bound with kqueue semantics and «#ifdef»-way seems to be 
completely messy..(
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

[Tony Parker via swift-corelibs-dev]

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, 
>>> 
 On 8 dec. 2015, at 16:56, Pierre Habouzit  wrote: 
 
 FWIW, this is my personal, let’s call it enlightened, opinion, based on my 
 knowledge of dispatch and my past extensive system programming experience 
 with Linux before I joined Apple. 
 
 I think that long term, the best way to maintain a Linux libdispatch port 
 is to go away from the libkqueue that tries to emulate kqueue fully, where 
 dispatch only needs a small subset of the surface of kqueue. Given how 
 source.c is written today, this is not a very small undertaking, but 
 eventually dispatch source map to epoll_ctl(EPOLLONESHOT) very very well. 
>>> 
>>> That makes sense, could simplify the implementation (and keep thing 
>>> cleaner). Then the follow up question is of course how to split/manage 
>>> source.c (as Daniel pointed out there is the merging issue). 
>> we can decide when/if someone tries to tackle it. I humbly recognize that I 
>> have no great idea of how to do so.
> 
> I have some experience in event multiplexing programming for linux. So it 
> looks like interesting project for me. There is some conceptual questions 
> which I think should be discussed:
> 
> 1) Obviously, kqueue and epoll have a little different semantics. For 
> example: in linux timers, signals and socket can be presented as file 
> descriptor and processed uniformly. Is there any chance that community will 
> agree to develop separate API for linux?

For what it’s worth, we went ahead and based CFRunLoop.c on Linux on top of 
epoll: 

https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/RunLoop.subproj/CFRunLoop.c
 


https://github.com/apple/swift-corelibs-foundation/commit/d594de1bdd7f10a558e30b92809420303ded0a6a#diff-9739b4f43fc59b19e677f9e3f835d159
 


I think it makes total sense for dispatch’s SPI for CF to simply return an 
eventfd.

- Tony

> 2) Does anyone have long term vision about how to inject platform specific 
> code into current implementation of dispatch_source? As far as I’ve read the 
> source it’s heavily bound with kqueue semantics and «#ifdef»-way seems to be 
> completely messy..(
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Starter bug: Run Foundation tests against OS X Foundation

[Ian Ynda-Hummel via swift-corelibs-dev]

Hey all,

I'd like to claim this one. I'll assign to myself on Jira.

On Thu, Dec 17, 2015 at 12:08 PM Tony Parker via swift-corelibs-dev <
swift-corelibs-dev@swift.org> wrote:

> Hi everyone,
>
> I filed a bug here that would be a great way for someone to jump into
> contributing to swift-corelibs-foundation:
>
> SR-276 
>
> The basic idea is that we could really use a way to run our Swift test
> suite against the system (OS X) Foundation. This will help everyone to
> verify that the behavior of the library we are building is the same as OS
> X. If it’s not, then we know we have a bug to resolve in some way.
>
> Let me know if you have any questions,
> - Tony
>
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Proposal: Make NSTask's standardInput/standardOutput/standardError properties type-safe

[Dan Stenmark via swift-corelibs-dev]

Hi Tony, thanks for the response!

In regards to why an enum w/ associated values:

- It avoids creating additional storage.  (Admittedly, a very small amount, but 
the point still stands.)
- It deterministically defines that it’s either one or the other, and guards 
against someone trying to be clever and setting both the Pipe and Handle 
properties.  Even if we do have a safeguard for that (like “setting the Pipe 
property nils out the File Handle property” and vice-versa), making it a 
type-safe enum improves API clarity.  I’m generally not a fan of implicit API 
behaviors that require reading the fine print, and while they are necessary 
sometimes, I’d much prefer the class’s declaration makes it clear from the 
get-go.  
- Furthermore on the previous point, it helps encourage safer client usage 
patterns for callers getting pre-launched NSTask objects from opaque factory 
methods.  (I don’t see this pattern out in the wild very much, but I don’t want 
to rule it out, especially if Swift starts taking off on the server-side).

Dan

> On Dec 17, 2015, at 12:31 PM, Tony Parker  wrote:
> 
> Hi Dan,
> 
> Thank you for your proposal. This is the right place to start discussion of 
> it. If we want to do this then we would have to make changes in both Darwin 
> and open source versions, to maintain source compatibility.
> 
> Out of curiosity, why propose an enum instead of an additional set of typed 
> properties? Looking at the implementation of NSTask, it sure seems like we 
> only expect either a file handle or pipe. I’m not sure if we would ever add 
> another.
> 
> - Tony
> 
>> On Dec 17, 2015, at 11:34 AM, Dan Stenmark via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> This is my first proposal to swift-corelibs, so I’m not sure how much 
>> flexibility we have in terms of deviating from the darwin’s original 
>> Foundation definitions.  That said, it’s always seemed a little screwy to me 
>> that NSTask's standardInput/standardOutput/standardError properties 
>> sacrifice any semblance of compile-time type safety by accepting 
>> id/AnyObject (which, at run time, must be either NSPipe or NSFileHandle, 
>> else it blows up).  If allowed, I’d like to take the opportunity to 
>> modernize this in the open source version of Foundation.
>> 
>> public class NSTask : NSObject {
>> 
>> ...
>> 
>> public enum IOType {
>> 
>> case FileHandle(NSFileHandle)
>> case Pipe(NSPipe)
>> }
>> 
>> public var standardInput: NSTask.IOType?
>> public var standardOutput: NSTask.IOType?
>> public var standardError: NSTask.IOType?
>> 
>> ...
>> 
>>
>> }
>> 
>> Dan
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

[Pierre Habouzit via swift-corelibs-dev]

> 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, 
 
> On 8 dec. 2015, at 16:56, Pierre Habouzit  wrote: 
> 
> FWIW, this is my personal, let’s call it enlightened, opinion, based on 
> my knowledge of dispatch and my past extensive system programming 
> experience with Linux before I joined Apple. 
> 
> I think that long term, the best way to maintain a Linux libdispatch port 
> is to go away from the libkqueue that tries to emulate kqueue fully, 
> where dispatch only needs a small subset of the surface of kqueue. Given 
> how source.c is written today, this is not a very small undertaking, but 
> eventually dispatch source map to epoll_ctl(EPOLLONESHOT) very very well. 
 
 That makes sense, could simplify the implementation (and keep thing 
 cleaner). Then the follow up question is of course how to split/manage 
 source.c (as Daniel pointed out there is the merging issue). 
>>> we can decide when/if someone tries to tackle it. I humbly recognize that I 
>>> have no great idea of how to do so.
>> 
>> I have some experience in event multiplexing programming for linux. So it 
>> looks like interesting project for me. There is some conceptual questions 
>> which I think should be discussed:
>> 
>> 1) Obviously, kqueue and epoll have a little different semantics. For 
>> example: in linux timers, signals and socket can be presented as file 
>> descriptor and processed uniformly. Is there any chance that community will 
>> agree to develop separate API for linux?
> 
> For what it’s worth, we went ahead and based CFRunLoop.c on Linux on top of 
> epoll: 
> 
> https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/RunLoop.subproj/CFRunLoop.c
> 
> https://github.com/apple/swift-corelibs-foundation/commit/d594de1bdd7f10a558e30b92809420303ded0a6a#diff-9739b4f43fc59b19e677f9e3f835d159
> 
> I think it makes total sense for dispatch’s SPI for CF to simply return an 
> eventfd.

it’s exactly what we want for runloop tied queues. The mach port that is used 
for this on Darwin receives messages only to break out of the mach_msg() call, 
but the handler of the message is a void function: 
_dispatch_wakeup_runloop_thread().

The good news is that a mach_port is an uint32_t and eventfd would be an int, 
so as far as storage is concerned, everything is fine.

I would have the _dispatch_get_main_queue_port_4CF / 
_dispatch_runloop_root_queue_get_port_4CF return an eventfd, and adapt the code 
that disposes of it. This is a IMO straightforward patch that should be written 
e.g. that way:

#if HAVE_MACH
// current OS X Code
#elif HAVE_EVENTFD
// linux port
#else
#error should not happen
#endif

And also have:

DISPATCH_COCOA_COMPAT be set to one on linux (until it is, you don’t get the 
main queue and runloop tied queues).


The one murky thing is that someone has to *consume* what’s in that eventfd, 
today, it’s implicit with mach because MiG will call dispatch’s 
_dispatch_wakeup_runloop_thread() for it (corresponding to the 
wakeup_runloop_thread routine in protocol.defs), but for linux, it’s probably 
best if CF knows that it’s an eventfd and it has to eventfd_read() from it to 
consume the event before it’s calling 
_dispatch_runloop_root_queue_perform_4CF(). The alternative is for 
_dispatch_runloop_root_queue_perform_4CF() to do that read in a non blocking 
way, but for the cases when several things have been queued on the runloop 
queue and have been coalesced in a single eventfd delivery, it’s a bit dumb to 
pay a syscall per dequeue.

On Mach the coalescing happens because the port has a queue width of 1 and 
incoming messages are dropped when the port is full.


-Pierre
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

[Pierre Habouzit via swift-corelibs-dev]

-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, Joakim Hassila via swift-corelibs-dev 
>  wrote: 
> 
> Hi, 
> 
>> On 8 dec. 2015, at 16:56, Pierre Habouzit  
>> wrote: 
>> 
>> FWIW, this is my personal, let’s call it enlightened, opinion, based on 
>> my knowledge of dispatch and my past extensive system programming 
>> experience with Linux before I joined Apple. 
>> 
>> I think that long term, the best way to maintain a Linux libdispatch 
>> port is to go away from the libkqueue that tries to emulate kqueue 
>> fully, where dispatch only needs a small subset of the surface of 
>> kqueue. Given how source.c is written today, this is not a very small 
>> undertaking, but eventually dispatch source map to 
>> epoll_ctl(EPOLLONESHOT) very very well. 
> 
> That makes sense, could simplify the implementation (and keep thing 
> cleaner). Then the follow up question is of course how to split/manage 
> source.c (as Daniel pointed out there is the merging issue). 
 we can decide when/if someone tries to tackle it. I humbly recognize that 
 I have no great idea of how to do so.
>>> 
>>> I have some experience in event multiplexing programming for linux. So it 
>>> looks like interesting project for me. There is some conceptual questions 
>>> which I think should be discussed:
>>> 
>>> 1) Obviously, kqueue and epoll have a little different semantics. For 
>>> example: in linux timers, signals and socket can be presented as file 
>>> descriptor and processed uniformly. Is there any chance that community will 
>>> agree to develop separate API for linux?
>> 
>> For what it’s worth, we went ahead and based CFRunLoop.c on Linux on top of 
>> epoll: 
>> 
>> https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/RunLoop.subproj/CFRunLoop.c
>> 
>> https://github.com/apple/swift-corelibs-foundation/commit/d594de1bdd7f10a558e30b92809420303ded0a6a#diff-9739b4f43fc59b19e677f9e3f835d159
>> 
>> I think it makes total sense for dispatch’s SPI for CF to simply return an 
>> eventfd.
> 
> it’s exactly what we want for runloop tied queues. The mach port that is used 
> for this on Darwin receives messages only to break out of the mach_msg() 
> call, but the handler of the message is a void function: 
> _dispatch_wakeup_runloop_thread().
> 
> The good news is that a mach_port is an uint32_t and eventfd would be an int, 
> so as far as storage is concerned, everything is fine.
> 
> I would have the _dispatch_get_main_queue_port_4CF / 
> _dispatch_runloop_root_queue_get_port_4CF return an eventfd, and adapt the 
> code that disposes of it. This is a IMO straightforward patch that should be 
> written e.g. that way:
> 
> #if HAVE_MACH
> // current OS X Code
> #elif HAVE_EVENTFD
> // linux port
> #else
> #error should not happen
> #endif
> 
> And also have:
> 
> DISPATCH_COCOA_COMPAT be set to one on linux (until it is, you don’t get the 
> main queue and runloop tied queues).
> 
> 
> The one murky thing is that someone has to *consume* what’s in that eventfd, 
> today, it’s implicit with mach because MiG will call dispatch’s 
> _dispatch_wakeup_runloop_thread() for it (corresponding to the 
> wakeup_runloop_thread routine in protocol.defs), but for linux, it’s probably 
> best if CF knows that it’s an eventfd and it has to eventfd_read() from it to 
> consume the event before it’s calling 
> _dispatch_runloop_root_queue_perform_4CF(). The alternative is for 
> _dispatch_runloop_root_queue_perform_4CF() to do that read in a non blocking 
> way, but for the cases when several things have been queued on the runloop 
> queue and have been coalesced in a single eventfd delivery, it’s a bit dumb 
> to pay a syscall per dequeue.
> 
> On Mach the coalescing happens because the port has a queue width of 1 and 
> incoming messages are dropped when the port is full.

Actually alternatively this could be done (no error handling for clarity, but 
it should have some!):


static bool
_dispatch_runloop_queue_drain_one(dispatch_queue_t dq)
{
if (!dq->dq_items_tail) {
#ifdef __linux__
eventfd_read((int)dq->do_ctxt, &(eventfd_t)0);
if (!dq->dq_items_tail) {
return false;
}
#else
return false;
#endif
}
...
}

IOW: consume the eventfd when we think the queue is empty, and check again it 
really is, that way you even have the eventfd break you out of the epoll while 
the queue is full which is probably nice (even if CF is supposed to already 
track this anyway, but I don’t know CFRunloop well so Tony should tell which 
alternative is better between my former mail or that one).

-Pierre
_

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

[Thomas Greany via swift-corelibs-dev]

What about libev? http://software.schmorp.de/pkg/libev.html

On Thu, Dec 17, 2015 at 12:36 PM, Dzianis Fedarenka via swift-corelibs-dev <
swift-corelibs-dev@swift.org> wrote:

> >> On Dec 10, 2015, at 12:42 AM, Joakim Hassila via swift-corelibs-dev
>  wrote:
> >>
> >> Hi,
> >>
> >>> On 8 dec. 2015, at 16:56, Pierre Habouzit 
> wrote:
> >>>
> >>> FWIW, this is my personal, let’s call it enlightened, opinion, based
> on my knowledge of dispatch and my past extensive system programming
> experience with Linux before I joined Apple.
> >>>
> >>> I think that long term, the best way to maintain a Linux libdispatch
> port is to go away from the libkqueue that tries to emulate kqueue fully,
> where dispatch only needs a small subset of the surface of kqueue. Given
> how source.c is written today, this is not a very small undertaking, but
> eventually dispatch source map to epoll_ctl(EPOLLONESHOT) very very well.
> >>
> >> That makes sense, could simplify the implementation (and keep thing
> cleaner). Then the follow up question is of course how to split/manage
> source.c (as Daniel pointed out there is the merging issue).
> > we can decide when/if someone tries to tackle it. I humbly recognize
> that I have no great idea of how to do so.
>
> I have some experience in event multiplexing programming for linux. So it
> looks like interesting project for me. There is some conceptual questions
> which I think should be discussed:
>
> 1) Obviously, kqueue and epoll have a little different semantics. For
> example: in linux timers, signals and socket can be presented as file
> descriptor and processed uniformly. Is there any chance that community will
> agree to develop separate API for linux?
> 2) Does anyone have long term vision about how to inject platform specific
> code into current implementation of dispatch_source? As far as I’ve read
> the source it’s heavily bound with kqueue semantics and «#ifdef»-way seems
> to be completely messy..(
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

[Pierre Habouzit via swift-corelibs-dev]

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 dispatch ported (for some reason your reply wasn’t attached to a 
mail thread for me and I got confused), and that one needs a raw interface with 
epoll to interact with CFRunlopp and that’s what I “replied” to.

I don’t think that moving away from likqueue is a good idea yet. Technically, 
dispatch is really interleaved with kqueue code, and libkqueue overhead is 
smaller than I originally thought, so I’ve kind of revisited that argument.

The one thing that will be painful for the port to an extent, is that kevents 
are now uniquified in kernel based on the ident + udata, said another way, if 
you watch the same file descriptor twice with two different udata’s, then it’s 
two different kevents in kernel. That is *NOT* the case with epoll, where 
uniquing is only based on the file-descriptor: if you EPOLL_CTL_ADD two 
different “udata” for the same fd, you get EEXIST, which means that you need to 
do multiplexing in userland (which dispatch used to do before kevent started 
taking udata into account).

That has impacts on the userland parallelism as all source registering and 
deregistering have to be serialized wrt each other. This is the hard part, not 
abstracting epoll.

-Pierre

> On Dec 17, 2015, at 1:44 PM, Thomas Greany via swift-corelibs-dev 
>  wrote:
> 
> What about libev? http://software.schmorp.de/pkg/libev.html 
> 
> 
> On Thu, Dec 17, 2015 at 12:36 PM, Dzianis Fedarenka via swift-corelibs-dev 
> mailto:swift-corelibs-dev@swift.org>> wrote:
> >> On Dec 10, 2015, at 12:42 AM, Joakim Hassila via swift-corelibs-dev 
> >> http://swift.org/>> wrote:
> >>
> >> Hi,
> >>
> >>> On 8 dec. 2015, at 16:56, Pierre Habouzit  >>> > wrote:
> >>>
> >>> FWIW, this is my personal, let’s call it enlightened, opinion, based on 
> >>> my knowledge of dispatch and my past extensive system programming 
> >>> experience with Linux before I joined Apple.
> >>>
> >>> I think that long term, the best way to maintain a Linux libdispatch port 
> >>> is to go away from the libkqueue that tries to emulate kqueue fully, 
> >>> where dispatch only needs a small subset of the surface of kqueue. Given 
> >>> how source.c is written today, this is not a very small undertaking, but 
> >>> eventually dispatch source map to epoll_ctl(EPOLLONESHOT) very very well.
> >>
> >> That makes sense, could simplify the implementation (and keep thing 
> >> cleaner). Then the follow up question is of course how to split/manage 
> >> source.c (as Daniel pointed out there is the merging issue).
> > we can decide when/if someone tries to tackle it. I humbly recognize that I 
> > have no great idea of how to do so.
> 
> I have some experience in event multiplexing programming for linux. So it 
> looks like interesting project for me. There is some conceptual questions 
> which I think should be discussed:
> 
> 1) Obviously, kqueue and epoll have a little different semantics. For 
> example: in linux timers, signals and socket can be presented as file 
> descriptor and processed uniformly. Is there any chance that community will 
> agree to develop separate API for linux?
> 2) Does anyone have long term vision about how to inject platform specific 
> code into current implementation of dispatch_source? As far as I’ve read the 
> source it’s heavily bound with kqueue semantics and «#ifdef»-way seems to be 
> completely messy..(
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
> 
> 
>  ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Starter bug: Run Foundation tests against OS X Foundation

[Tony Parker via swift-corelibs-dev]

Awesome, thanks Ian!

- Tony

> On Dec 17, 2015, at 12:54 PM, Ian Ynda-Hummel  wrote:
> 
> Hey all,
> 
> I'd like to claim this one. I'll assign to myself on Jira.
> 
> On Thu, Dec 17, 2015 at 12:08 PM Tony Parker via swift-corelibs-dev 
> mailto:swift-corelibs-dev@swift.org>> wrote:
> Hi everyone,
> 
> I filed a bug here that would be a great way for someone to jump into 
> contributing to swift-corelibs-foundation:
> 
> SR-276 
> 
> The basic idea is that we could really use a way to run our Swift test suite 
> against the system (OS X) Foundation. This will help everyone to verify that 
> the behavior of the library we are building is the same as OS X. If it’s not, 
> then we know we have a bug to resolve in some way.
> 
> Let me know if you have any questions,
> - Tony
> 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
> 

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Git history

[Tom Jowett via swift-corelibs-dev]

Completely agree re: not wishing to be pedantic and I know this represents
such a tiny part of the overall scope of the project (ie it's much more
important that we have a full library vs a perfect commit history).

I'll try and put together a couple of scenarios based on the current
history and how they could be rebased to follow your guidelines. I'll shoot
these back to the list for everyone to look over. I'll also try cleaning up
a couple of PR's in the backlog and pushing them up to my own fork just to
walk people through they could be a bit cleaner.

All of this aside, it's really quite amazing how well this project is
coming along. Thanks for all your involvement.

Cheers,
Tom
On Thu, 17 Dec 2015 at 8:58 AM, Tony Parker 
wrote:

> Hi Tom,
>
> I’ve actually been thinking about this a lot over the past few days, but
> haven’t come to any real conclusion yet.
>
> The way I’ve traditionally worked on Foundation is that each commit has
> more content, and each commit is (almost) always associated with a bug.
> This is basically the process I had in mind when I wrote the CONTRIBUTING
> document.
>
> However, we’re at such an early stage in this project now that I don’t
> want to add a lot of overhead to PRs that contain basic functionality. I’m
> also grateful for all of the work that everyone is putting in, and don’t
> want to put off potential contributors with an overly pedantic policy.
> We’re trying as hard as we can to keep up with everything, but some PRs are
> sitting for some time before we can fully review them, which means they are
> inevitably out of date and have to be rebased.
>
> I think that as more projects start to depend upon the library we will
> have to be much more cautious about how we accept changes, how they are
> tested, and how they are structured (e.g., for easier reverting).
>
> I welcome additional thoughts on this topic.
>
> Thanks,
> - Tony
>
> On Dec 17, 2015, at 1:25 AM, Tom Jowett via swift-corelibs-dev <
> swift-corelibs-dev@swift.org> wrote:
>
> Hi everyone,
>
> I'm wondering if there's a way I can help to keep the commit structure of
> the repo a bit tidier?  I can see the guideline being provided
> on CONTRIBUTING.md however the current commit history could be a little
> easier to follow for the average viewer (eb06d19 and b4f6e2b were duplicate
> commits, e.g) and it seems the rebase before PR element of that guideline
> could be better followed.
>
> Perhaps a link in CONTRIBUTING.md to a walkthrough on how to squash and
> rebase commits (including adding tests appropriately for bisect) could be
> helpful?  Happy to put one together in the context of this project if you
> think so.  Also interested in any other suggestions you might have for how
> this could be remedied.
>
> Cheers,
> Tom
>
>
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>
>
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-corelibs-dev] NSThread properties

[Joseph Bell via swift-corelibs-dev]

Reading the Status page I see that NSThread is "fully implemented", yet.
when looking at the code and verifying by compiling, none of the properties:

executing
finished
cancelled

are implemented.

Is this an oversight or was it decided to not implement these properties?

Double-checking before I file an SR.

Thanks,
Joe
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSThread properties

[Tony Parker via swift-corelibs-dev]

Hi Joe,

Looks like an oversight. We should add them.

- Tony

> On Dec 17, 2015, at 6:45 PM, Joseph Bell via swift-corelibs-dev 
>  wrote:
> 
> Reading the Status page I see that NSThread is "fully implemented", yet. when 
> looking at the code and verifying by compiling, none of the properties:
> 
> executing
> finished
> cancelled
> 
> are implemented.
> 
> Is this an oversight or was it decided to not implement these properties?
> 
> Double-checking before I file an SR.
> 
> Thanks,
> Joe
> 
>  ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSThread properties

[Joseph Bell via swift-corelibs-dev]

Thanks Tony, https://bugs.swift.org/browse/SR-303 has been filed.

On Thu, Dec 17, 2015 at 8:53 PM, Tony Parker 
wrote:

> Hi Joe,
>
> Looks like an oversight. We should add them.
>
> - Tony
>
> On Dec 17, 2015, at 6:45 PM, Joseph Bell via swift-corelibs-dev <
> swift-corelibs-dev@swift.org> wrote:
>
> Reading the Status page I see that NSThread is "fully implemented", yet.
> when looking at the code and verifying by compiling, none of the properties:
>
> executing
> finished
> cancelled
>
> are implemented.
>
> Is this an oversight or was it decided to not implement these properties?
>
> Double-checking before I file an SR.
>
> Thanks,
> Joe
>
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>
>
>
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

[Daniel A. Steffen via swift-corelibs-dev]

> On Dec 17, 2015, at 13:41, Pierre Habouzit via swift-corelibs-dev 
>  wrote:
> 
> 
> -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, Joakim Hassila via swift-corelibs-dev 
>>  wrote: 
>> 
>> Hi, 
>> 
>>> On 8 dec. 2015, at 16:56, Pierre Habouzit  
>>> wrote: 
>>> 
>>> FWIW, this is my personal, let’s call it enlightened, opinion, based on 
>>> my knowledge of dispatch and my past extensive system programming 
>>> experience with Linux before I joined Apple. 
>>> 
>>> I think that long term, the best way to maintain a Linux libdispatch 
>>> port is to go away from the libkqueue that tries to emulate kqueue 
>>> fully, where dispatch only needs a small subset of the surface of 
>>> kqueue. Given how source.c is written today, this is not a very small 
>>> undertaking, but eventually dispatch source map to 
>>> epoll_ctl(EPOLLONESHOT) very very well. 
>> 
>> That makes sense, could simplify the implementation (and keep thing 
>> cleaner). Then the follow up question is of course how to split/manage 
>> source.c (as Daniel pointed out there is the merging issue). 
> we can decide when/if someone tries to tackle it. I humbly recognize that 
> I have no great idea of how to do so.
 
 I have some experience in event multiplexing programming for linux. So it 
 looks like interesting project for me. There is some conceptual questions 
 which I think should be discussed:
 
 1) Obviously, kqueue and epoll have a little different semantics. For 
 example: in linux timers, signals and socket can be presented as file 
 descriptor and processed uniformly. Is there any chance that community 
 will agree to develop separate API for linux?
>>> 
>>> For what it’s worth, we went ahead and based CFRunLoop.c on Linux on top of 
>>> epoll: 
>>> 
>>> https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/RunLoop.subproj/CFRunLoop.c
>>> 
>>> https://github.com/apple/swift-corelibs-foundation/commit/d594de1bdd7f10a558e30b92809420303ded0a6a#diff-9739b4f43fc59b19e677f9e3f835d159
>>> 
>>> I think it makes total sense for dispatch’s SPI for CF to simply return an 
>>> eventfd.
>> 
>> it’s exactly what we want for runloop tied queues. The mach port that is 
>> used for this on Darwin receives messages only to break out of the 
>> mach_msg() call, but the handler of the message is a void function: 
>> _dispatch_wakeup_runloop_thread().
>> 
>> The good news is that a mach_port is an uint32_t and eventfd would be an 
>> int, so as far as storage is concerned, everything is fine.
>> 
>> I would have the _dispatch_get_main_queue_port_4CF / 
>> _dispatch_runloop_root_queue_get_port_4CF return an eventfd, and adapt the 
>> code that disposes of it. This is a IMO straightforward patch that should be 
>> written e.g. that way:
>> 
>> #if HAVE_MACH
>> // current OS X Code
>> #elif HAVE_EVENTFD
>> // linux port
>> #else
>> #error should not happen
>> #endif
>> 
>> And also have:
>> 
>> DISPATCH_COCOA_COMPAT be set to one on linux (until it is, you don’t get the 
>> main queue and runloop tied queues).
>> 
>> 
>> The one murky thing is that someone has to *consume* what’s in that eventfd, 
>> today, it’s implicit with mach because MiG will call dispatch’s 
>> _dispatch_wakeup_runloop_thread() for it (corresponding to the 
>> wakeup_runloop_thread routine in protocol.defs)

actually that is never called, the only thing that is used is the mig server 
routine _dispatch_send_wakeup_runloop_thread, the client routine is just there 
so that the mig client code links…

>> , but for linux, it’s probably best if CF knows that it’s an eventfd and it 
>> has to eventfd_read() from it to consume the event before it’s calling 
>> _dispatch_runloop_root_queue_perform_4CF(). The alternative is for 
>> _dispatch_runloop_root_queue_perform_4CF() to do that read in a non blocking 
>> way, but for the cases when several things have been queued on the runloop 
>> queue and have been coalesced in a single eventfd delivery, it’s a bit dumb 
>> to pay a syscall per dequeue.
>> 
>> On Mach the coalescing happens because the port has a queue width of 1 and 
>> incoming messages are dropped when the port is full.
> 
> Actually alternatively this could be done (no error handling for clarity, but 
> it should have some!):
> 
> 
> static bool
> _dispatch_runloop_queue_drain_one(dispatch_queue_t dq)
> {
>   if (!dq->dq_items_tail) {
> #ifdef __linux__
>   eventfd_read((int)dq->do_ctxt, &(eventfd_t)0);
>   if (!dq->dq_items_tail) {
>   return false;
>   }
> #else
>   return false;
> #endif
>  

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

[Daniel A. Steffen via swift-corelibs-dev]

> On Dec 17, 2015, at 21:16, Daniel A. Steffen via swift-corelibs-dev 
>  wrote:
> 
>> 
>> On Dec 17, 2015, at 13:41, Pierre Habouzit via swift-corelibs-dev 
>>  wrote:
>> 
>> 
>> -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, Joakim Hassila via swift-corelibs-dev 
>>>  wrote: 
>>> 
>>> Hi, 
>>> 
 On 8 dec. 2015, at 16:56, Pierre Habouzit  
 wrote: 
 
 FWIW, this is my personal, let’s call it enlightened, opinion, based 
 on my knowledge of dispatch and my past extensive system programming 
 experience with Linux before I joined Apple. 
 
 I think that long term, the best way to maintain a Linux libdispatch 
 port is to go away from the libkqueue that tries to emulate kqueue 
 fully, where dispatch only needs a small subset of the surface of 
 kqueue. Given how source.c is written today, this is not a very small 
 undertaking, but eventually dispatch source map to 
 epoll_ctl(EPOLLONESHOT) very very well. 
>>> 
>>> That makes sense, could simplify the implementation (and keep thing 
>>> cleaner). Then the follow up question is of course how to split/manage 
>>> source.c (as Daniel pointed out there is the merging issue). 
>> we can decide when/if someone tries to tackle it. I humbly recognize 
>> that I have no great idea of how to do so.
> 
> I have some experience in event multiplexing programming for linux. So it 
> looks like interesting project for me. There is some conceptual questions 
> which I think should be discussed:
> 
> 1) Obviously, kqueue and epoll have a little different semantics. For 
> example: in linux timers, signals and socket can be presented as file 
> descriptor and processed uniformly. Is there any chance that community 
> will agree to develop separate API for linux?
 
 For what it’s worth, we went ahead and based CFRunLoop.c on Linux on top 
 of epoll: 
 
 https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/RunLoop.subproj/CFRunLoop.c
 
 https://github.com/apple/swift-corelibs-foundation/commit/d594de1bdd7f10a558e30b92809420303ded0a6a#diff-9739b4f43fc59b19e677f9e3f835d159
 
 I think it makes total sense for dispatch’s SPI for CF to simply return an 
 eventfd.
>>> 
>>> it’s exactly what we want for runloop tied queues. The mach port that is 
>>> used for this on Darwin receives messages only to break out of the 
>>> mach_msg() call, but the handler of the message is a void function: 
>>> _dispatch_wakeup_runloop_thread().
>>> 
>>> The good news is that a mach_port is an uint32_t and eventfd would be an 
>>> int, so as far as storage is concerned, everything is fine.
>>> 
>>> I would have the _dispatch_get_main_queue_port_4CF / 
>>> _dispatch_runloop_root_queue_get_port_4CF return an eventfd, and adapt the 
>>> code that disposes of it. This is a IMO straightforward patch that should 
>>> be written e.g. that way:
>>> 
>>> #if HAVE_MACH
>>> // current OS X Code
>>> #elif HAVE_EVENTFD
>>> // linux port
>>> #else
>>> #error should not happen
>>> #endif
>>> 
>>> And also have:
>>> 
>>> DISPATCH_COCOA_COMPAT be set to one on linux (until it is, you don’t get 
>>> the main queue and runloop tied queues).
>>> 
>>> 
>>> The one murky thing is that someone has to *consume* what’s in that 
>>> eventfd, today, it’s implicit with mach because MiG will call dispatch’s 
>>> _dispatch_wakeup_runloop_thread() for it (corresponding to the 
>>> wakeup_runloop_thread routine in protocol.defs)
> 
> actually that is never called, the only thing that is used is the mig server 
> routine _dispatch_send_wakeup_runloop_thread, the client routine is just 
> there so that the mig client code links…
> 
>>> , but for linux, it’s probably best if CF knows that it’s an eventfd and it 
>>> has to eventfd_read() from it to consume the event before it’s calling 
>>> _dispatch_runloop_root_queue_perform_4CF(). The alternative is for 
>>> _dispatch_runloop_root_queue_perform_4CF() to do that read in a non 
>>> blocking way, but for the cases when several things have been queued on the 
>>> runloop queue and have been coalesced in a single eventfd delivery, it’s a 
>>> bit dumb to pay a syscall per dequeue.
>>> 
>>> On Mach the coalescing happens because the port has a queue width of 1 and 
>>> incoming messages are dropped when the port is full.
>> 
>> Actually alternatively this could be done (no error handling for clarity, 
>> but it should have some!):
>> 
>> 
>> static bool
>> _dispatch_runloop_queue_drain_one(dispatch_queue_t dq)
>> {
>>  if (!dq->dq_items_tail) {
>> #ifdef __linux__
>>