I've posted a snippet in the so question:
```go
l, err := net.Listen("tcp", ":2000")if err != nil {
log.Fatal(err)
}
for {
conn, err := l.Accept() // BLOCKING HERE
...
}
```
iiuc, your solution only checks on the start as eventually you have to
call `l.Accept()` and be blocked again.
you can modify the above code in any way where it'd receive a signal
(e.g. Ctrl+C) and breaks out of either `l.Accept` or stops
`net.listen`, either works.
On Mon, Jul 24, 2023 at 9:39 AM Bakul Shah <ba...@iitbombay.org> wrote:
> You can do a non-blocking select on a channel prior to l.Accept(). If
> there is a pause message, you do a blocking select on the same channel for
> an resume or finish message. A separate goroutine can send you those
> messages depending on conditions under which you want to pause or resume.
>
> If the above doesn't make sense write a sample program on play.golang.org,
> which does roughly want you want except for pause/resume, and post a link
> here and we can modify it for pause/resume.
>
> On Jul 21, 2023, at 10:47 PM, David N <danowz...@gmail.com> wrote:
>
> I've posted this question on stackoverflow
> <https://stackoverflow.com/questions/76447195/how-to-suspend-and-resume-accepting-new-connections-in-net-listener>,
> discussed it with some members of the golang community, and I was
> encouraged to post here.
>
> Problem: I have a secure application and I want to pause/resume accepting
> network connections, calling `l.Accept()` blocks the thread, thus you can't
> pause in a single-thread program. You can use goroutines but that still
> isn't ideal, as the routine would still accept the connection first and
> only then can close it if you're in "pause" mode.
>
> This could be solved by:
> - having a non-blocking, async, `l.Accept()`
> - returning a handle to (accepting) goroutine and killing/re-creating it
> from main thread
> - accepting connections in a separate process and communicating over a
> socket
>
> The 1st one doesn't exist, the 2nd one is not accepted by the language
> designers, and the 3rd one is unnecessarily complex and prone to break.
>
> This looks like a shortcoming of golang, is it worth discussing further
> with lang designers?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAN7%3DS7htWfYUQmd3H8GiWoWSaei1qU-FMcpqdyccFkXN1kmsWg%40mail.gmail.com
> <https://groups.google.com/d/msgid/golang-nuts/CAN7%3DS7htWfYUQmd3H8GiWoWSaei1qU-FMcpqdyccFkXN1kmsWg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAN7%3DS7jaB3b49oxyz9d4otsqGqDuQdcnigd9qvV0%3DasX172-AA%40mail.gmail.com.
