Re: [racket-dev] feature request: thread-safe memoize-evt
Thanks for your time. On Thu, 2015-01-29 at 12:55 -0700, Matthew Flatt wrote: Would the simpler `once-evt` work in your situation, or do you need the guarantee that only one wait of E happens at a time? OK, my original goal is to implement a remote method call multiplexer. The kind where you send a message with an identifier and the remote party eventually replies with the same identifier or possibly with a well-known one to indicate an out-of-bound notification. So, I'd like to end up with (something-receive-evt something key) and (something-call-evt something key request). I can see two ways to do that; 1. Have a dispatch table with pending messages. 2. Broadcast all incoming messages to all waiters. Dispatch table requires non-racy invalidation of pending requests to prevent resource leaks. Broadcasting messages requires construction of a thread-safe memoizing event combinator (produces next-evt and a single result). Also, I have a feeling that I could get close to (1) if I keep some cleanup thread and utilize nack-guard-evt, but something tells me it might be racy. Best regards, Jan Dvorak _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] feature request: thread-safe memoize-evt
On Thu, 2015-01-29 at 16:41 -0600, Robby Findler wrote: That is, I thought you could just create a separate thread that sync's on E_b and then whenever you get a value from it, then the E_m would just continue to produce that all the time. But I think you're saying that wouldn't work? The problem is that the auxiliary thread would always wait for the E_b, even when nobody is interested in the result anymore. Moreover, putting the wait in another thread would require the E_b to be thread safe. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] feature request: thread-safe memoize-evt
Hi, I would like to ask for another extension of the Racket's event handling system. A `memoize-evt` constructor with following semantics: Given a base event E_b, memoize-evt will produce a memoizing event E_m. Synchronizing on E_m from any number of threads will block until a single value is produced by E_b. This value is then stored inside the E_m. From that moment on, E_m will always be immediately ready for synchronization and produce the stored value in all waiting threads. The single-threaded implementation is a trivial guard-evt + replace-evt + (wrap-evt always-evt) combo, but for thread-safety a temporary thread would be needed to wait for the base event and the solution would have different semantics then rest of the event system. A lower-level approach would also be possible; create something along the lines of a dynamic-wind-evt that would, with some cleverness, allow for generic thread-safe events via locking. Or create a locked-wrap-evt constructor that will not be ready until it's handler finishes. Hoping that I am not being too bothersome, from Prague with thanks, Jan Dvorak _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] pkgs.racket-lang.org
Hi, about the http://pkgs.racket-lang.org/ - the site is getting rather large. Wouldn't server-side filtering work better than the client javascript solution? Plus I often have trouble submitting new packages, the form could easily be done in the traditional way and the experience would be much better. Adding a package would be an atomic operating, unlike the current situation where I have to fill out some fields three times before they register correctly. [Firefox on Fedora 20, x86_64] Best regards, Jan Dvorak _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] BUG: busy-waiting
Hello, I am hitting a rather uncomfortable bug that causes runtime to start internal busy-waiting at around: #0 scheme_block_until(_f=syncing_ready, fdf=scheme_syncing_needs_wakeup) at ../src/thread.c:5199 #1 do_sync (name=sync, with_break=0, with_timeout=0) at ../src/thread.c:7109 It goes through ../src/thread.c:5190, which Matthew mentions in one of his recent patches. The code that manages to trigger this have been written under NDA and cannot be published. I have not yet managed to reproduce the issue separately, but it seems that this might not be the only instance: (09:28:36 PM) m4burns: Mordae: I'm having a similar problem somewhere in `inflate`. Haven't applied a debugger yet, but there's certainly no busy waiting in the script. I am stuck and would like to ask for your help. Best regards, Jan Dvorak _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current packages' docs, errors, and conflicts
On Tue, 2014-07-08 at 12:46 +0100, Matthew Flatt wrote: The rightmost column of the table may need some explanation. The column highlights conflicts among names of package-installed executables, foreign libraries, and documents. Currently, all the conflicts are document names, because several packages have a documents named simply manual or main. Can you provide some guidelines on docs naming? I am responsible for half of the conflicts. :-) Best regards, Jan Dvorak _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current packages' docs, errors, and conflicts
On Tue, 2014-07-08 at 13:14 +0100, Matthew Flatt wrote: A package X that provides a collection X of the same name should probably also call its documentation X. Thanks, I've fixed mine. Looking forward to having pkg-docs at a single place. :-) _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] request: replace-evt
Hi, I would like to humbly request a new `replace-evt` procedure that would work as `wrap-evt` except that when it produces another `evt?`, `sync` replaces the old event with the newly produced one and restarts. It will be a good replacement for threads and channels when filtering events or addition of bookkeeping handlers is desired. I peeked at the syncing code and it seems doable, but the code is too dense for me to grok it. :-( What do you think? Best regards, Jan Dvorak _ Racket Developers list: http://lists.racket-lang.org/dev
