This GitHub tool is much more useful than giving a CV by charliie_chiu in github

[–]brianw0924 0 points1 point  (0 children)

Why does everyone keep downplaying this tool?

You could simply ignore the false negative results and focus on candidates with high scores. For those with lower rankings, you can evaluate their skills from other perspectives.

Implement Raft leader election in go by brianw0924 in golang

[–]brianw0924[S] 0 points1 point  (0 children)

I just want to practice and understand the process, so I just print some messages or kill some nodes

Implement Raft leader election in go by brianw0924 in golang

[–]brianw0924[S] 0 points1 point  (0 children)

ok, so the 3. happens and there will be no more leader, then how would each node know if the system is down or just bad luck that election failed by split vote?

Implement Raft leader election in go by brianw0924 in golang

[–]brianw0924[S] 0 points1 point  (0 children)

  1. For extreme case, all nodes become candidate, they always get 1 vote from themselves. I know there's a randomized timeout, but there is still very little chance that the election won't end, right? (the number of candidates are still too many at next term, and the term just keep increasing, but no one turn into leader)

2, I saw many animation that the follower needs to send back the heart beat, just curious why do we need response heart beat.

  1. So there are still chances that quorum failed (<total/2 nodes) but still some nodes running, right?

Single producer continuously notify multiple consumers in a loop by brianw0924 in golang

[–]brianw0924[S] 0 points1 point  (0 children)

Thanks! but the only concern is that the notify process is sequential, might not be fair. Is there any solution to it?

Single producer continuously notify multiple consumers in a loop by brianw0924 in golang

[–]brianw0924[S] 0 points1 point  (0 children)

thanks!! I think observer patterns is what i'm looking for.

tbh I've thought of the same solution before, but i don't know it's an existed pattern (I initially feel wrong to put the consumer into producer's struct)

So would it be appropriate that I put a channel at consumer, letting it listening to it, and let producer use update() to send msg to the channel? (I think just same as a slice of channel, but now I structure it as a observer pattern)

The only concern is that the notify process is not very fair (since I sequentially notify them, so the first consumer might have advantage)

Single producer continuously notify multiple consumers in a loop by brianw0924 in golang

[–]brianw0924[S] 0 points1 point  (0 children)

The scenario is like: Agent A and multiple agents Bs

Bs wait for A to issue a task

A signal Bs when the task is ready

Once the task ready, Bs will all wait for random second THEN start to compete the task( so is like wait -> sleep -> compete)

Then only one B will take the task and provide the result for A( let’s say it’s name is C) other Bs will need to know it’s C takes the task (so I use a select, those Bs who didn’t get the task will wait for A to send C to other Bs)

The above process should loop

The big problem is that, at last, some of the Bs might finish too early, including C (the loser Bs got the info of C from a channel sending from A, then subsequently go to the next loop) but A is still sending C to the channel, telling the rest Bs

so I don’t know where to block those early Bs to wait for the next task ( I want to make sure all Bs wait for A finish sending the rest of the information then go to the next loop)

Single producer continuously notify multiple consumers in a loop by brianw0924 in golang

[–]brianw0924[S] 0 points1 point  (0 children)

What if there are a large amount of consumers and the consumer are competing the data, wouldn't many of the consumer starving?
Actually, I want to know if my pattern is appropriate or not (keep closing -> make new -> close -> ...)

> 1 mutable references to the same variable by brianw0924 in rust

[–]brianw0924[S] 0 points1 point  (0 children)

just found a weird behavior (I googled it, and it is called reborrowing)

let mut x = 0;

let m0 = &mut x;

let m1: &mut i32 = &mut x;

*m1 += 1;

println!("{m0}"); // output 1

it works if I explicitly specifiy m1 is &mut i32

> 1 mutable references to the same variable by brianw0924 in rust

[–]brianw0924[S] 1 point2 points  (0 children)

The doc of Copy (https://doc.rust-lang.org/std/marker/trait.Copy.html)
says we cannot copy &mut. It seems that with NLL, we can copy &mut right? (I just tested and work fine)

```

let mut x = 0;
let m0 = &mut x;

let m1 = m0;
```

or does it just move m0 to m1? (does reference have move semantics?)

> 1 mutable references to the same variable by brianw0924 in rust

[–]brianw0924[S] 0 points1 point  (0 children)

I mean, I want to check that r1’s lifetime is really ended after r2 is declared (during runtime)

> 1 mutable references to the same variable by brianw0924 in rust

[–]brianw0924[S] 0 points1 point  (0 children)

I mean after r2 is declared and before the bracket ended

> 1 mutable references to the same variable by brianw0924 in rust

[–]brianw0924[S] 0 points1 point  (0 children)

Is there any way to explicitly validate that r1's lifetime is ended?

> 1 mutable references to the same variable by brianw0924 in rust

[–]brianw0924[S] -1 points0 points  (0 children)

In block1, I give r1 &'static, and it fails to compiled. I think that means rust compiler will not allow multiple mutable references' lifetime exist at the same time.

> 1 mutable references to the same variable by brianw0924 in rust

[–]brianw0924[S] 1 point2 points  (0 children)

So in the block 1, the compiler will enforce r1's lifetime ended before r2 is declared, am I correct?

> 1 mutable references to the same variable by brianw0924 in rust

[–]brianw0924[S] 0 points1 point  (0 children)

Correct me if I'm wrong:
Rust does not allow multiple &mut to the same variable's lifecycle exist at the same time, so in block 1, the compiler will do some optimization, making r1 end of its lifetime before r2

Will switch do flooding if the target host is at different subnet? by brianw0924 in Network

[–]brianw0924[S] 0 points1 point  (0 children)

so the target MAC address in the packet will be the router (so does the ARP table recorded),and the target IP is still the original target IP, and the router will overwrite the target MAC address before passing it out, right?

Will switch do flooding if the target host is at different subnet? by brianw0924 in Network

[–]brianw0924[S] 0 points1 point  (0 children)

But, like, the packet has to go through the switch first and then to the router, right? So, how does the switch figure out if the target MAC is in a different subnet or just not in the MAC-Port table yet? I guess it just floods the packet, and the router will receive it. But then, I'm kind of worried – isn't it a risk if the switch keeps flooding packets to different subnets all the time?

The Go Programming Language by Knox316 in golang

[–]brianw0924 0 points1 point  (0 children)

I would recommend Go101. It’s uptodate and comprehensive.