I thought I'd start a thread for this potential GSoC project, since we've had a bit of interest expressed in it privately.
To be clear, at this point in the process, what we're after from potential GSoC students is a written proposal; Google provides some guidelines on doing that that you might care to read.
If multiple people are interested in the same project, we'll pick the best proposal to go forward to the next stage. At that point, the Swift team will rank the proposals we've received according to the priorities of the overall project, and that list will go to Google, who will make the final decision about which ones will go ahead.
I’m interested in helping implementing this feature!
I previously contributed to swift-java interoperability and I would really like to explore the Swift compiler!
In the last 4 days I worked on 3 PRs (1 merged, 1 approved, 1 waiting for review) in the swift compiler, I am now familiar with building, manual testing, and running tests in the swift compiler!
I also researched a bit to look for relevant code and found out that:
We'd need a new class for the new data structure
Add a Task to our tracking in swift_task_create_commonImpl in stdlib/public/Concurrency/Task.cpp
Add a TaskGroup to our tracking in _swift_taskGroup_initialize in stdlib/public/Concurrency/TaskGroup.cpp
I wanted your help to learn more about the project.
I have a few questions:
Relevant code for Concurrency runtime in the swift compiler that are we going to change (that I should learn more and understand)?
Relevant atomic and memory ordering library that we'd like to research and use (I previously used std::atomic when implementing a thread pool in C++ but I didn't dive deep into memory_order since mutex, condition_variable was enough in my case)
We want to reduce the use of locking not limit it to zero, right?
Do you have suggested data structure in mind or this is a task left for me? (This reminds me when I implemented malloc and had to choose between different memory allocation algorithms “I am excited“)
Should I start doing a proof of concept PR or just do something similar in the proposal?
Is there anything else you would recommend to help me become more familiar with the project and make a better proposal?
After having a draft proposal, can I send it to you for review?
I would appreciate your guidance on the next steps.
I would have thought std::atomic would work for us here.
I don't think we will want locking in the hot path here; the danger is that adding locks in the wrong place will cause all concurrent code to have to funnel through a single lock, unintentionally serialising it to some degree. And we don't want that.
I have an idea or two, but I don't want to share that up front because if this proposal runs, I would like the person working on it to think about it themselves — maybe you will turn out to have a better idea in mind than the one I've been pondering. And maybe not, but I think part of this project is to investigate potential data structures and see which ones might work best.
I wouldn't start working on it yet. The thing we need at this stage is a proposal. Don't forget that (a) Google may not allocate a GSoC slot for this project, and (b) even if they do, it's possible multiple people are interested and so your proposal might not be chosen.
I suspect this is going to have to be done in C++ because of the atomics, but it's worth pondering whether we can in fact do it on the Swift side instead.
I'd also suggest being cautious about thinking you could use thread-local or per-executor storage here to somehow avoid locking. The problem with that is that a Task can be scheduled and re-scheduled, and end on a different thread to the one it started out on. Similarly with executors.
Absolutely, and the same applies to anyone else interested.