8 ms·

RunWithScissors() (2009)

43 points by tentacleuno 3y ago

28304283409234 3y ago
Obligatory: Face your fears, from Crazy Ex-girlfriend. https://www.youtube.com/watch?v=brzZQBSVMX0 https://www.youtube.com/watch?v=brzZQBSVMX0
danpalmer 3y ago
A less amusing name, but similar effect – `dangerouslySetInnerHTML` from React. https://legacy.reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml https://legacy.reactjs.org/docs/dom-elements.html#dangerousl...
- rmilejczz 3y ago
  This function name amuses me because it implies there is a “safelySetInnerHTML” method Also shouts out to the UNSAFE_component methods, you’re a real hipster if you used those before the prefix
  - can16358p 3y ago
    Not exactly. If you are putting something inside the tag in React, you are implitly setting inner HTML the React way, managed by the virtual DOM. This method (actually not even a method but an attribute that probably calls a method if set) "bypasses" React to set the inner HTML of the element, hence "dangerous". (But I get what you mean of course, the reply was not to you but anyone who isn't familiar with React)
    - rmilejczz 3y ago
      You’re right it’s not even a method lol it’s a custom dom attribute. I had no idea
- initplus 3y ago
  Or ‘accursedUnutterablePerformIO’ from Haskell https://hackage.haskell.org/package/bytestring-0.11.4.0/docs/Data-ByteString-Internal.html#v:accursedUnutterablePerformIO https://hackage.haskell.org/package/bytestring-0.11.4.0/docs...
  - bradrn 3y ago
    The documentation is itself fairly funny, for those who don’t care to click ahead: > This "function" has a superficial similarity to ‘unsafePerformIO’ but it is in fact a malevolent agent of chaos. It unpicks the seams of reality (and the IO monad) so that the normal rules no longer apply. It lulls you into thinking it is reasonable, but when you are not looking it stabs you in the back and aliases all of your mutable buffers. The carcass of many a seasoned Haskell programmer lie strewn at its feet. > Witness the trail of destruction: https://github.com/haskell/bytestring/commit/71c4b438c675aa360c79d79acc9a491e7bbc26e7 https://github.com/haskell/bytestring/commit/210c656390ae617d9ee3b8bcff5c88dd17cef8da https://ghc.haskell.org/trac/ghc/ticket/3486 https://ghc.haskell.org/trac/ghc/ticket/3487 https://ghc.haskell.org/trac/ghc/ticket/7270 https://gitlab.haskell.org/ghc/ghc/-/issues/22204 > Do not talk about "safe"! You do not know what is safe! > Yield not to its blasphemous call! Flee traveller! Flee or you will be corrupted and devoured!
    - gizmo686 3y ago
      Originally, that function was just called "inlinePerformIO", with the relatively tame warning of: > Just like unsafePerformIO, but we inline it. Big performance gains as it exposes lots of things to further inlining. Very unsafe. In particular, you should do no memory allocation inside an inlinePerformIO block. On Hugs this is just unsafePerformIO https://hackage.haskell.org/package/bytestring-0.9/docs/Data-ByteString-Internal.html#v%3AinlinePerformIO https://hackage.haskell.org/package/bytestring-0.9/docs/Data... At some point, this function was moved to the newly created "Deprecated and unmentionable" group of functions with the comment > Deprecated: If you think you know what you are doing, use unsafePerformIO. If you are sure you know what you are doing, use unsafeDupablePerformIO. If you enjoy sharing an address space with a malevolent agent of chaos, try accursedUnutterablePerformIO. At this point, the two depreciated and unmentionable functions were actually just aliases of each other, with InlinePerformIO being depreciated, and accursedUnutterablePerformIO being merely unmentionable. https://hackage.haskell.org/package/bytestring-0.10.10.1/docs/src/Data.ByteString.Internal.html#inlinePerformIO https://hackage.haskell.org/package/bytestring-0.10.10.1/doc... It wasn't until version 0.11.0.0 that the friendly sounding name was finally removed.
nraynaud 3y ago
stupid question: are the limitations testable in an assert to reduce the risks?
leoh 3y ago
This in some ways evokes for me the worst of Google engineering and culture. It’s documented in a nice way and with a gentle tone, but it’s fundamentally a method on top of broken behavior and a ton of tech debt. Yes, it’s not uncommon for folks engage like this in software; but once you’ve worked with individuals that think deeply about these kinds of issues and regularly, you start to see there’s another way.
- klodolph 3y ago
  What? Can you explain what broken behavior you’re talking about? Some things in concurrent programming can result in deadlocks. That doesn’t mean that you round off all the corners and take away all the dangerous tools until you’re left with a kiddie playground as a programming environment. No, instead it means that the more experienced programmers on your team keep a sharp eye on how concurrency / multithreading is used in your program.
  - empiricus 3y ago
    When I needed to use this function, it was because the Android API to run things asynchronously using Handler.post()/remove() seems to be incomplete. You want to remove() a runnable, but maybe that runnable is executing in parallel exactly when you want to remove it. Depending on what you application does, this will cause various issues. The simplest way to fix issues in this case is to synchronize the threads using RunWithScissors. In short: the API is simple and easy to use, but it allows for strange cornercases, and you need a hack like RunWithScissors. That function is a hack because for various other reasons related to the rest of the API and the way it is implemented, it may block forever in some other cornercase. So maybe we can say this is broken behavior and an bad/incomplete API.
    - klodolph 3y ago
      That makes sense. Not making excuses for the API—but this does seem like a difficult design space to work in.
- natnat 3y ago
DeathArrow 3y ago
This reminds me of Running with Scissors, the game company who made Postal games. Maybe the author was a fan of those games?
- teunispeters 3y ago
  I'm more thinking of Weird Al Yankovic's album "Running with Scissors" (1999).
empiricus 3y ago
Fun memories: we had some bug in some application, and we reviewed the possible fixes in a meeting. "The fix is simple and relatively safe, the only issue is that we need to use a function called runWithScissors".
- s_gourichon 3y ago
  IMHO this is the effect expected by the people who named the function, and the reason why the name is very well chosen. Yes, it's funny but that's not the point. The important thing is that the name clearly conveys the message that you really shouldn't be calling it, as explained in the comments above the function definition. The "funny but there's a real reason behind" aspect is a bit like https://xkcd.com/radiation/ https://xkcd.com/radiation/ : "It's for general education only. If you're basing radiation safety procedures on an internet PNG image and things go wrong, you have no one to blame but yourself." The sentence is funny but has a real purpose: protect readers and author.
wisienkas 3y ago
I was very surprised to see that there was an inconsistency between the constructors as well as the fields placed after all the methods and private and public methods mixed and matched in order, trying to see what mLooper was about. I would not have approved this code.
charles_f 3y ago
Wow the quality of code comments is over the top! > If we ever do make it part of the API, we might want to rename it to something less funny like runUnsafe(). I wonder, when you write that, why you wouldn't chose to rename it right away rather than using a funny name? Is it a strategy to avoid people using it? (runUnsafeAvoidUsing) or a strategy to make sure it doesn't get into the API? (wouldn't a flag or runUnsafeDontMakeItIntoTheApibe better )?
- notRobot 3y ago
  The comment could've been written after the function was named?

43 points by tentacleuno 3y ago

Obligatory: Face your fears, from Crazy Ex-girlfriend. https://www.youtube.com/watch?v=brzZQBSVMX0 https://www.youtube.com/watch?v=brzZQBSVMX0

danpalmer 3y ago

A less amusing name, but similar effect – `dangerouslySetInnerHTML` from React. https://legacy.reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml https://legacy.reactjs.org/docs/dom-elements.html#dangerousl...

rmilejczz 3y ago
This function name amuses me because it implies there is a “safelySetInnerHTML” method Also shouts out to the UNSAFE_component methods, you’re a real hipster if you used those before the prefix
- can16358p 3y ago
  Not exactly. If you are putting something inside the tag in React, you are implitly setting inner HTML the React way, managed by the virtual DOM. This method (actually not even a method but an attribute that probably calls a method if set) "bypasses" React to set the inner HTML of the element, hence "dangerous". (But I get what you mean of course, the reply was not to you but anyone who isn't familiar with React)
  - rmilejczz 3y ago
    You’re right it’s not even a method lol it’s a custom dom attribute. I had no idea
initplus 3y ago
Or ‘accursedUnutterablePerformIO’ from Haskell https://hackage.haskell.org/package/bytestring-0.11.4.0/docs/Data-ByteString-Internal.html#v:accursedUnutterablePerformIO https://hackage.haskell.org/package/bytestring-0.11.4.0/docs...
- bradrn 3y ago
  The documentation is itself fairly funny, for those who don’t care to click ahead: > This "function" has a superficial similarity to ‘unsafePerformIO’ but it is in fact a malevolent agent of chaos. It unpicks the seams of reality (and the IO monad) so that the normal rules no longer apply. It lulls you into thinking it is reasonable, but when you are not looking it stabs you in the back and aliases all of your mutable buffers. The carcass of many a seasoned Haskell programmer lie strewn at its feet. > Witness the trail of destruction: https://github.com/haskell/bytestring/commit/71c4b438c675aa360c79d79acc9a491e7bbc26e7 https://github.com/haskell/bytestring/commit/210c656390ae617d9ee3b8bcff5c88dd17cef8da https://ghc.haskell.org/trac/ghc/ticket/3486 https://ghc.haskell.org/trac/ghc/ticket/3487 https://ghc.haskell.org/trac/ghc/ticket/7270 https://gitlab.haskell.org/ghc/ghc/-/issues/22204 > Do not talk about "safe"! You do not know what is safe! > Yield not to its blasphemous call! Flee traveller! Flee or you will be corrupted and devoured!
  - gizmo686 3y ago
    Originally, that function was just called "inlinePerformIO", with the relatively tame warning of: > Just like unsafePerformIO, but we inline it. Big performance gains as it exposes lots of things to further inlining. Very unsafe. In particular, you should do no memory allocation inside an inlinePerformIO block. On Hugs this is just unsafePerformIO https://hackage.haskell.org/package/bytestring-0.9/docs/Data-ByteString-Internal.html#v%3AinlinePerformIO https://hackage.haskell.org/package/bytestring-0.9/docs/Data... At some point, this function was moved to the newly created "Deprecated and unmentionable" group of functions with the comment > Deprecated: If you think you know what you are doing, use unsafePerformIO. If you are sure you know what you are doing, use unsafeDupablePerformIO. If you enjoy sharing an address space with a malevolent agent of chaos, try accursedUnutterablePerformIO. At this point, the two depreciated and unmentionable functions were actually just aliases of each other, with InlinePerformIO being depreciated, and accursedUnutterablePerformIO being merely unmentionable. https://hackage.haskell.org/package/bytestring-0.10.10.1/docs/src/Data.ByteString.Internal.html#inlinePerformIO https://hackage.haskell.org/package/bytestring-0.10.10.1/doc... It wasn't until version 0.11.0.0 that the friendly sounding name was finally removed.

nraynaud 3y ago

stupid question: are the limitations testable in an assert to reduce the risks?

leoh 3y ago

This in some ways evokes for me the worst of Google engineering and culture. It’s documented in a nice way and with a gentle tone, but it’s fundamentally a method on top of broken behavior and a ton of tech debt. Yes, it’s not uncommon for folks engage like this in software; but once you’ve worked with individuals that think deeply about these kinds of issues and regularly, you start to see there’s another way.

klodolph 3y ago
What? Can you explain what broken behavior you’re talking about? Some things in concurrent programming can result in deadlocks. That doesn’t mean that you round off all the corners and take away all the dangerous tools until you’re left with a kiddie playground as a programming environment. No, instead it means that the more experienced programmers on your team keep a sharp eye on how concurrency / multithreading is used in your program.
- empiricus 3y ago
  When I needed to use this function, it was because the Android API to run things asynchronously using Handler.post()/remove() seems to be incomplete. You want to remove() a runnable, but maybe that runnable is executing in parallel exactly when you want to remove it. Depending on what you application does, this will cause various issues. The simplest way to fix issues in this case is to synchronize the threads using RunWithScissors. In short: the API is simple and easy to use, but it allows for strange cornercases, and you need a hack like RunWithScissors. That function is a hack because for various other reasons related to the rest of the API and the way it is implemented, it may block forever in some other cornercase. So maybe we can say this is broken behavior and an bad/incomplete API.
  - klodolph 3y ago
    That makes sense. Not making excuses for the API—but this does seem like a difficult design space to work in.
natnat 3y ago

DeathArrow 3y ago

This reminds me of Running with Scissors, the game company who made Postal games. Maybe the author was a fan of those games?

teunispeters 3y ago
I'm more thinking of Weird Al Yankovic's album "Running with Scissors" (1999).

empiricus 3y ago

Fun memories: we had some bug in some application, and we reviewed the possible fixes in a meeting. "The fix is simple and relatively safe, the only issue is that we need to use a function called runWithScissors".

s_gourichon 3y ago
IMHO this is the effect expected by the people who named the function, and the reason why the name is very well chosen. Yes, it's funny but that's not the point. The important thing is that the name clearly conveys the message that you really shouldn't be calling it, as explained in the comments above the function definition. The "funny but there's a real reason behind" aspect is a bit like https://xkcd.com/radiation/ https://xkcd.com/radiation/ : "It's for general education only. If you're basing radiation safety procedures on an internet PNG image and things go wrong, you have no one to blame but yourself." The sentence is funny but has a real purpose: protect readers and author.

wisienkas 3y ago

I was very surprised to see that there was an inconsistency between the constructors as well as the fields placed after all the methods and private and public methods mixed and matched in order, trying to see what mLooper was about. I would not have approved this code.

charles_f 3y ago

Wow the quality of code comments is over the top! > If we ever do make it part of the API, we might want to rename it to something less funny like runUnsafe(). I wonder, when you write that, why you wouldn't chose to rename it right away rather than using a funny name? Is it a strategy to avoid people using it? (runUnsafeAvoidUsing) or a strategy to make sure it doesn't get into the API? (wouldn't a flag or runUnsafeDontMakeItIntoTheApibe better )?

notRobot 3y ago
The comment could've been written after the function was named?