Re: [racket-users] Breaking semaphores

It isn't clear to me either. I can't think of a use case for it, but I'm hoping either somebody else can or somebody can confirm that it's not a good API precedent. I'm trying to build some concurrency libraries and I'd like to be sure there

Re: [racket-users] Breaking semaphores

I don’t personally have any problems with Racket’s semaphore interface as it exists today. I think having the choice of whether or not to enable breaks mostly makes sense as something the ambient environment controls, not individual pieces of synchronization logic, since you usually want

Re: [racket-users] Breaking semaphores

Killing a thread is different from breaking a thread. Killing a thread kills the thread unrecoverably, and no cleanup actions are run. This usually isn’t what you want, but there’s always a tension between these kinds of things: defensive programmers ask “How do I make myself unkillable so I

Re: [racket-users] Breaking semaphores

I don't see how it has to do with semaphores being low-level. If waiting on a semaphore while breaks are enabled is almost certainly wrong, checking whether breaks are enabled and raising an error seems like a way more sensible default behavior than just silently doing something that's almost

Re: [racket-users] Breaking semaphores

Like I said, it isn’t clear to me that all uses of `semaphore-wait` when breaks are enabled are incorrect. You could argue that then you should have a `semaphore-wait/trust-me-even-though-breaks-are-enabled`, and sure, I don’t think that would necessarily be bad. I just imagine the API just

Re: [racket-users] Breaking semaphores

I am making a new concurrency abstraction, and I already have to work around the interface because it forces me to make this choice at every use site. What I was planning on doing was pushing this decision into the value itself, rather than the use site. So what if `make-semaphore` had a

Re: [racket-users] Breaking semaphores

I appreciate the sentiment about prior art, but I'm already familiar with both of those links and a significant part of my day job involves working on concurrency frameworks. Specific use cases are more what I'm after. For instance, what would you like to use mutexes for? On Sat, Jan 18, 2020 at

Re: [racket-users] Breaking semaphores

I would use mutexes in relatively standard ways, I think, to protect critical sections that access shared mutable state or external resources that may require some form of serialization. The usual approach of using a semaphore works fine, but it does require the aforementioned break

Re: [racket-users] Breaking semaphores

I do understand all of that, and you're right that "kill-safe" isn't what I meant. What I'm confused about is why, if it's inherently not guaranteed to leave the semaphore in a consistent state, semaphore-wait attempts to work at all if breaks are enabled. Why not raise some helpful error like

Re: [racket-users] Breaking semaphores

Actually, I change my mind, I can trivially think of a case where it’s fine: if you’re just using a semaphore as an event. One thread waits with `semaphore-wait`, another thread calls `semaphore-post`, and after the count is decremented, it’s never re-incremented. It’s just used to gate

Re: [racket-users] Re: Installing Drracket on linux penguin on Chromebook

Hi, If the architecture is aarch64 then most likely you'll need to build from source. In the University of Utah snapshot builds there is an armv6 build, but most likely this won't work,  but is worth trying.

Re: [racket-users] Breaking semaphores

No, I don’t think so, and here’s why: imagine a library provides an abstraction that internally uses semaphores as events. The library uses `semaphore-wait` to wait on the event. The client of this library now has the option to disable breaks if it turns out this code is actually going to be

Re: [racket-users] Breaking semaphores

Oh, an addendum: I would be remiss not to mention the excellent paper on the design of Haskell’s asynchronous exception system, which provides both examples of problems in the wild and more general elaboration on both the design space and the particular point within it the authors chose for

Re: [racket-users] Breaking semaphores

Is there a specific instance where you were writing some code and thought mutexes would help, or is there a specific project with a problem you'd like to solve with mutexes? Or IVars and LVars? I started down this road because I noticed that the test result counting

Re: [racket-users] Breaking semaphores

It is guaranteed to leave the semaphore in a consistent state, from the perspective of the implementation of semaphores. No matter what you do, you won’t ever corrupt a semaphore (assuming you’re not using unsafe operations and assuming the runtime is not buggy). But perhaps you mean

Re: [racket-users] Breaking semaphores

Wouldn't you want to *force* the first thread to wait with semaphore-wait/enable-break in that case? Since if they're disabled then that thread can't be cooperatively terminated. If you use `semaphore-wait` it seems like you completely hand off control over whether breaks are enabled or not, which

Re: [racket-users] Breaking semaphores

Oh: something more ambitious that I would enjoy having would be an implementation of IVars and LVars to avoid needing to think about locking entirely. > On Jan 18, 2020, at 05:00, Alexis King wrote: > >  > I would use mutexes in relatively standard ways, I think, to protect critical >