-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ready-event allocation #114
Comments
Uh oh: |
Update: breaks can be re-enabled inside a region where breaks are disabled (just like parameterizations) so this ought to be possible using helpers like this: (define (unbreakable-evt evt)
(guard-evt (λ () (parameterize-break #f (sync evt)))))
(define (breakable-evt evt)
(guard-evt (λ () (parameterize-break #t (sync evt))))) Then, with disposable allocation and deallocation defined in terms of events, a disposable that needs to wait arbitrarily could use these helpers to specify when breaking is or isn't allowed. But this might be a bad idea. I'll have to find out more about how events and breaks interact. |
Turns out the way (define (pair-evt a b)
(define left (handle-evt a (cons 'left _)))
(define right (handle-evt b (cons 'right _)))
(replace-evt (choice-evt left right)
(match-lambda
[(cons 'left v) (handle-evt b (cons v _))]
[(cons 'right v) (handle-evt a (cons _ v))]))) Something built on top of this ought to be capable of replacing the current |
Attempting to make a disposable with
tcp-accept
and port closing is undesirable, because waiting for a connection could take an arbitrarily long time and disposable allocation is called with breaks disabled. Instead, such a disposable should work by creating an event that is ready for synchronization when a connection is established, and guarantees no connection was created if it's not chosen for synchronization. A helper for constructing these sorts of disposables would help people avoid doing things the wrong way. Something like this:(define my-disposable (disposable-evt <evt-alloc> <evt-result-dealloc>))
Which is equivalent to this...
Thanks for the idea @BourgondAries!
The text was updated successfully, but these errors were encountered: