Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEAT] add golang like channel #1843
base: master
Are you sure you want to change the base?
[FEAT] add golang like channel #1843
Changes from 1 commit
8f72e01
83654b8
da02f54
1945a2e
58af665
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since it seems like this is meant to be used as the interface and
Chan(<int>) new = BufferedChan(<int, 1>){}.init()!!;
is quite hacky as this essentially does this:consider making this a method instead and allocating the
BufferedChan
on the heap:which would be used as
Chan(<int>) foo = buffered_chan::new(<int, 123>)()
ofc this would require freeing the channel once you are done with it so in
BufferedChan.destroy
you can addfree(self)
.passing the allocator to new would allow for
fn Chan(<Type>)! temp() => new(allocator::temp())
to create a channel on the temporary allocator.the same should also be done to
UnbufferedChan
you could also remove the
Chan
interface and keep things how they are but instead used like this:or
but this would come with the drawback of other libraries/functions being able to take any type of channel like how allocators are used.
this is just a dump of all my thoughts, you can choose what you want as long as @lerno is fine with it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reasons of the constructor being implemented like this are the following:
but i don't mind to redo it)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BufferedChan signature
(<Type, SIZE>)
is fully stolen from ring buffer (in reality i just reimplemented ring buffer with some quirks specific to channel)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a fairness mechanism?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you mean if the thread came and locked first - then it is getting the value first? - no
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to make it work we need some sort of mechanism to
awake/send to sleep
specific threadThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if we have this mechanism, then instead of
send_waiting/read_waiting
we can uselinkedlist
wich stores threadsThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something like that. Or that each thread will eventually pop a value from the channel, provided there are sufficient values available. It is guaranteed that no thread will be starved (i.e., some threads consuming all the values while others never get a chance to pop any value).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually i have an idea how to implement it - we can create a cond for every thread and keep this conds in LiknedList - this will guarantee us the order of awaking of threads is the same as the order of them going to wait
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but i think it's gonna be very inefficient