# Run infinite loop in future for message-passing style?
**URL:** https://racket.discourse.group/t/run-infinite-loop-in-future-for-message-passing-style/1265
**Category:** Questions & Answers
**Created:** [August 31, 2022, 6:30am UTC](https://racket.discourse.group/t/run-infinite-loop-in-future-for-message-passing-style/1265 "2022-08-31T06:30:12Z")
**Posts on this page:** 13
**Page:** 1
### Author:  [@dannypsnl](https://racket.discourse.group/u/dannypsnl)
#### Post date: [August 31, 2022, 6:30am UTC](https://racket.discourse.group/t/run-infinite-loop-in-future-for-message-passing-style/1265/1 "2022-08-31T06:30:12Z")
I write the code like the following
```scheme
(struct process (fu ch))
(define (process-send pro msg)
(async-channel-put (process-ch pro) msg))
(define (^friend my-name)
(define ch (make-async-channel))
(define self (future
(thunk (let loop ()
(match (async-channel-get ch)
[(list 'ping from)
(printf "ping from ~a~n" my-name)
(process-send from 'pong)
(loop)]
['pong
(printf "pong from ~a~n" my-name)
(loop)])))))
(process self ch))
(let ([bob (^friend "Bob")]
[jack (^friend "Jack")])
(process-send bob (list 'ping jack)))
```
But unless I let `future` get an ending(by `touch`), it will not really print anything, should I expect the above works? Or there have problems I didn't know about with the abstraction.
---
### Author:  [@bogdan](https://racket.discourse.group/u/bogdan)
#### Post date: [August 31, 2022, 7:37am UTC](https://racket.discourse.group/t/run-infinite-loop-in-future-for-message-passing-style/1265/2 "2022-08-31T07:37:42Z")
Futures aren't the right abstraction for what you're trying to do. You should use `thread`s if single-core concurrency is good enough for your use case, or `place`s if you need parallelism. Futures are mainly useful for parallelising operations that don't require synchronisation (eg. parallel number crunching).
Blocking operations (like `async-channel-get`) suspend futures until they are `touch`ed and memory allocations can temporarily pause future execution, too. See [this section of the guide](https://docs.racket-lang.org/guide/parallelism.html#%28tech._future%29) for an explanation.
---
### Author:  [@dannypsnl](https://racket.discourse.group/u/dannypsnl)
#### Post date: [August 31, 2022, 9:30am UTC](https://racket.discourse.group/t/run-infinite-loop-in-future-for-message-passing-style/1265/3 "2022-08-31T09:30:02Z")
Well, I want something that wasn't as heavy as `place`s to do tiny jobs and talk to each other. Seems like I don't have suitable choices.
---
### Author:  [@benknoble](https://racket.discourse.group/u/benknoble)
#### Post date: [August 31, 2022, 1:17pm UTC](https://racket.discourse.group/t/run-infinite-loop-in-future-for-message-passing-style/1265/4 "2022-08-31T13:17:30Z")
I would use threads for that.
---
### Author:  [@dannypsnl](https://racket.discourse.group/u/dannypsnl)
#### Post date: [August 31, 2022, 2:52pm UTC](https://racket.discourse.group/t/run-infinite-loop-in-future-for-message-passing-style/1265/5 "2022-08-31T14:52:31Z")
Well, that's already the current solution, but still didn't quite fit my imagination.
If you would like to see the code, here it is: [sauron/record-maintainer.rkt at develop · racket-tw/sauron · GitHub](https://github.com/racket-tw/sauron/blob/develop/collect/record-maintainer.rkt)
---
### Author:  [@samth](https://racket.discourse.group/u/samth)
#### Post date: [August 31, 2022, 4:23pm UTC](https://racket.discourse.group/t/run-infinite-loop-in-future-for-message-passing-style/1265/6 "2022-08-31T16:23:40Z")
Your code seems to be focused on concurrency, not getting parallel speedup (as you would expect for "tiny jobs") and thus threads are exactly the right thing. What are you imagining that's different?
---
### Author:  [@dannypsnl](https://racket.discourse.group/u/dannypsnl)
#### Post date: [August 31, 2022, 5:49pm UTC](https://racket.discourse.group/t/run-infinite-loop-in-future-for-message-passing-style/1265/7 "2022-08-31T17:49:09Z")
The problem comes from a more complex situation, I think each maintainer should notify its dependencies modules' maintainers about its use of the definitions from them, this makes a huge impact because many messages are blocked in the background. Hence, each thread gets only a little time to handle messages.
The thread that the editor currently using didn't get any special treatment, however, so this makes the front end blocked. This is the reason why I'm looking for something and parallel processing their own messages.
---
### Author:  [@samth](https://racket.discourse.group/u/samth)
#### Post date: [August 31, 2022, 6:21pm UTC](https://racket.discourse.group/t/run-infinite-loop-in-future-for-message-passing-style/1265/8 "2022-08-31T18:21:31Z")
If the problem is _blocking_ then parallelism won't help.
---
### Author:  [@dannypsnl](https://racket.discourse.group/u/dannypsnl)
#### Post date: [August 31, 2022, 7:45pm UTC](https://racket.discourse.group/t/run-infinite-loop-in-future-for-message-passing-style/1265/9 "2022-08-31T19:45:19Z")
How? Won't they get more resources rather than waiting for same core?
---
### Author:  [@samth](https://racket.discourse.group/u/samth)
#### Post date: [August 31, 2022, 8:00pm UTC](https://racket.discourse.group/t/run-infinite-loop-in-future-for-message-passing-style/1265/10 "2022-08-31T20:00:17Z")
It depends what you mean by "blocking". If you mean that you're waiting for something to finish before doing something else, then doing that thing faster will of course be helpful. (But note that doing something 2x faster is unlikely to make something that seems slow into something that seems fast, especially with other things running on the machine.) But if you mean that one things shouldn't have to wait for some other thing to finish (which is usually the case with UIs) then you need to use concurrency and just running things faster won't fix it.
---
### Author:  [@dannypsnl](https://racket.discourse.group/u/dannypsnl)
#### Post date: [August 31, 2022, 9:23pm UTC](https://racket.discourse.group/t/run-infinite-loop-in-future-for-message-passing-style/1265/11 "2022-08-31T21:23:32Z")
Oh, I guess I pick the wrong word XD. I mean to say **Each thread gets many messages to handle** , and then the frequent context switching crashes the performance.
---
### Author:  [@simonls](https://racket.discourse.group/u/simonls)
#### Post date: [September 1, 2022, 11:11pm UTC](https://racket.discourse.group/t/run-infinite-loop-in-future-for-message-passing-style/1265/12 "2022-09-01T23:11:15Z")
> [@dannypsnl](#):
>
> The thread that the editor currently using didn't get any special treatment, however, so this makes the front end blocked.
Maybe that thread should be special? For example it could be higher up in a hierarchy of threads, to ensure that it gets more of the available cpu time, maybe you could use [14.8 Thread Groups](https://docs.racket-lang.org/reference/threadgroups.html) to do that.
If you do this and it helps, would be interesting to hear about how you have used thread groups and how they work out in practice. So far I haven't used them, or seen a nice example where they get used.
---
### Author:  [@dannypsnl](https://racket.discourse.group/u/dannypsnl)
#### Post date: [September 2, 2022, 6:49am UTC](https://racket.discourse.group/t/run-infinite-loop-in-future-for-message-passing-style/1265/13 "2022-09-02T06:49:52Z")
I think the problem is `thread-group` is static? I'm not sure, but if it's, the code would be hard to write.
For example, I might have to share the cached data with a thread that has a higher group.