Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
matrixbot
@matrixbot
dpc notify.rs was meant to be only for one side single receiver.
dpc I'm quite sure for sync_channel two instances of broadcast.rs should be enough
dpc Also in Receiver for mpsc there is no need to notify the sender, since senders can never block, as the queue is unbounded.
Ravi Teja
@tekjar
I'll get back to this again on weekend
Dawid Ciężarkiewicz
@dpc
Great! Cu around
Dawid Ciężarkiewicz
@dpc
@tekjar I've implemented the mutex and pushed some other fixes.
Ravi Teja
@tekjar
@dpc Awesome :)
Dawid Ciężarkiewicz
@dpc
Async File is ready.
I mean ... started ... :D
But working.
Ravi Teja
@tekjar
That's fantastic @dpc. I'm about to take a stab at SyncSender.
:D
Ravi Teja
@tekjar
Hi @dpc
matrixbot
@matrixbot
dpc Hello
Ravi Teja
@tekjar
pub struct SyncSender<T> {
    tx: Option<mpsc::SyncSender<T>>,
    broadcast_rx: broadcast::Receiver,
    broadcast_tx: broadcast::Sender,
}
Is this what you want for SyncSender
?
matrixbot
@matrixbot
dpc I think so, yes.
dpc broadcast is a way to notify potentially multiple waiters.
dpc And in sync channel on empty / full fibers will wait for other side to wake them up.
Ravi Teja
@tekjar
In that case, Receiver should also be changed to use broadcast Receiver instead of notify Receiver
I mean in unbounder channel
unbounded*
Receiver uses notify
matrixbot
@matrixbot
dpc I don't think we need to have the same Receiver for both like in std.
Ravi Teja
@tekjar
Oh is it
matrixbot
@matrixbot
dpc SyncSender, SyncReceiver is OK I guess ...
dpc I feel like std might have made mistake there ...
Ravi Teja
@tekjar
Cool. I was trying to fit stuff in Receiver :P
matrixbot
@matrixbot
dpc Just because so happens that sync and unbounded channel are the same doesn't mean that future implementation will be like that ...
dpc Got to sleep! Take care.
Ravi Teja
@tekjar
so SyncReceiver will also have broadcast Sender to wakeup SyncSender fiber? Because SyncSender::send() will wait when channel is full
Oh alright. Will talk to you tomorrow
Ravi Teja
@tekjar
Hey @dpc . I've made the changes that you suggested. If possible can you please add some notes to struct members and other important places in broadcast.rs.
matrixbot
@matrixbot
dpc Sure. You can add comments as well
dpc I haven't anticipated help ☺️
Ravi Teja
@tekjar
I didn't understand it very well yet :P
Dawid Ciężarkiewicz
@dpc
Ha. Which parts exactly?
Peter Majchrak
@petoknm
Hello! What happened to the documentation link? https://dpc.github.io/mioco/ seems broken
@dpc ^^^
Dawid Ciężarkiewicz
@dpc
mioco old repository was renamed. I am not actively working on it.
The code in the mioco repo is not a new code, that I was toying with planing to simplify and rewrite
Peter Majchrak
@petoknm
Im looking for a green threading library... can you recommend something else?
Dawid Ciężarkiewicz
@dpc
I haven't been following on the subject much.
Now that Rust is getting stackless coroutines and generators, there might be better ones.
Peter Majchrak
@petoknm
alright... thanks anyway
Sawchord
@Sawchord
Hey @dpc, I was digging into the code recently... I think it is better to split up the lib.rs into individual files.
I don't think, that the file stays manageable, when the project grows.
Also we should take visibility into consideration.
I made an attempt of separating the things out and managing visibility.
Mainly, I introduced a LoopHandle, which budles the LoopTx, Poll and JoinHandle
What do you think?
I did not file a PR yet, since I am not completely done yet
matrixbot
@matrixbot
dpc Which codebase are we talking about? I'm not really working on mioco anymore.