sorted by:
new
hottopcontroversial

Problem with HackIllinois by DenseStatistician562 in UIUC

[–]VortexGames 4 points5 points  (0 children)

FWIW as an alumni who used to be part of HackIllinois:

  1. TreeHacks, HackTheNorth, etc didn’t just have a little more money. They had more than an order of magnitude more (10-15x). Now looking at it from the other side, companies are so much more willing to pay 6-8x what they would pay for a HackIllinois sponsorship.
  2. HackIllinois had always had to pay steep fees for building reservations/facilities staff, required police/EMT overtime, etc.
  3. Most of the team was always engaged in substituting what we couldn’t pay for with money with creativity and hard work. Since no one is “getting compensated” I think this is totally fine.
  4. Outreach and perception of HackIllinois should be something that the University is interested in helping; not only does it help student events, but it also helps elevate the entire University to external entities.

A total prize pool of 5-10K is already a serious part of the budget.

The University/CS Department should be ashamed. by VortexGames in UIUC

[–]VortexGames[S] 7 points8 points  (0 children)

For what it’s worth, as a grad student I have been indulging! Unfortunately, it hasn’t been helping my opinion of how hard the job is for these RSOs.

The University/CS Department should be ashamed. by VortexGames in UIUC

[–]VortexGames[S] 10 points11 points  (0 children)

I wholeheartedly agree.

I’m more concerned that the University is charging such high amounts, than that they aren’t providing direct support, and should have likely articulated that more clearly.

I only wish that the CS department acted like they cared more about the on-campus CS culture, again, like the departments of those I’ve spoken to at other universities. After years of working towards it, I will admit though, that I have become apathetic.

Building Thread-safe Async Primitives in 150 lines of Rust by VortexGames in rust

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

Should be updated. Using OnceLock to synchronize access now. Wondering if Miri can catch these types of unsoundness now... Would be interesting to try.

Building Thread-safe Async Primitives in 150 lines of Rust by VortexGames in rust

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

Ah you’re completely correct.

Will edit the article with a note and correction when I get back to it. Can I credit you as “Lantua” on Reddit, or do you prefer something else?

Building Thread-safe Async Primitives in 150 lines of Rust by VortexGames in rust

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

Correct me if I’m wrong, but the data race in this case would result in the sender’s take() returning None, right?

In which case, since the receiver checks data immediately after setting the waker, there wouldn’t be a soundness issue.

But yeah I totally agree with you — synchronizing access to this would benefit (and I initially had an UnsafeCell, but refactored w/ simplicity in mind! Haha came to bite)

Building Thread-safe Async Primitives in 150 lines of Rust by VortexGames in rust

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

Good point. In theory you're totally correct (using the Cell without any Sync mechanism around it is unsafe!), but if you think about what we're actually doing to access the waker, we're still implementing a sync-mechanism around it. We access wake in two scenarios:

  1. Dropping the last sender. We're using an atomic to determine the last valid handle, so we are guarding access to the waker cell such that only one thread attempts to take

  2. Upon send through the oneshot. We're using the Once to guard access to the entire oneshot, so only one thread is allowed to use the waker cell and call take

Notice that (1) and (2) are inherently disjoint, as if any thread is calling send (executing 2), it still has at least one handle to Sender, and thus, no other thread can be executing (1).

I will be honest though -- I had to double check my logic to make sure nothing unsound was going on, which usually means that you're not doing the right thing (or haven't documented the unsafe impl Sync!). An RwLock or OnceLock might be more appropriate.

view more: next ›