Proposal: expose tea.msg to handle multithreading scenarios

[Adjective-Object]

I'm using bubbletea as a persistent UI in a logger.
The logger has its own main loop that receives messages from multiple routines, and in that loop, calls tea.Send() on some subset of messages.

Unfortunately, if the program self-exits, there's a possibility that the loop deadlocks if a message is received by the main loop before we know the tea program has exited or not, because tea.Send() blocks when there is no receiver on the other side of the channel.

The canonical go solution would to do something like this

teaProg := tea.Program(myProg{})
teaExited := make(chan error)
go func() {
  // notify when tea is done
  teaExited <- teaProg.Start()
}()

go func() {
  // in my main loop
  select  {
  case tea.msg <- someMessage:
  case <-teaExited:
    // clean up the tea program, and
    // stop trying to send messages to tea
  }
}

there's a similar problem if you try to Quit() a dead tea program.

I was wondering if it makes sense to expose the tea message channel so it could be selected on.

Spitballing on alternatives, I thought for a bit about if this would be possible to implement internally without exposing the message channel, but I think if multiple routines are calling tea.Send(), the only way to guarantee that all of them recieve the teaExited message is if a goroutine that infinitely writes to teaExited is leaked on program quit, which doesn't seem acceptable.
Or, if you try to react to teaExited in Send() and set a flag, then we either have a possible race with simultaneous writes after the program exits, or have to put a lock around every call to tea.Send(). And locking on every Send() seems like it would be really bad for perf to me.

[Thunder33345]

have you consider checking out this example?

which allows the modal to subscribe your own channel, which allows you to use standard channel management pattern (so you can perform non blocking send, etc etc)

focus on waitForActivity function which returns a tea.Cmd that does a blocking read on the channel until a response is recieved, and the response handling inside the Update, which is to return a new waitForActivity command to read and wait for the next item in the channel

[Adjective-Object]

I'm pretty sure that example will non-deterministically drop commands when processing effectful messages at the same time as exiting the program.

More concretely: In my application, I have a logger goroutine, which, depending on if the tea app is running or not, will log them through the tea app via tea.Program.Send(someLoggerMessageStruct), which is processed by the update loop, which in turn returns a tea.Printf message.

So, in order to detect when the tea program has exited and log to stdout, we do this:

select {
   case bubbleTeaMessageChannel <- someLoggerMessageStruct:
   case <- loggerHasExited:
     // log via stdout instead, and set a flag to never log through bubbletea again
}

Where loggerHasExited is populated by a goroutine running:

go func() {
  tea.Start()
  loggerHasExited<-true
}

In the proposed solution, in this sequence of events, we drop a message:

1. model Init returns waitForActivity
2. The tea cmd loop consumes the waitForActivity, spawns a goroutine that is reading from sub here. It blocks on reading from sub.
3. The tea program returns tea.Quit from some unrelated message handling (e.g. user presses Ctrl+C)
4. The tea program returns, a message is written to loggerHasExited.
5. A message is logged to my logger loop. It tries to select from among writing to sub and reading from loggerHasExited. There is a ready reader on sub, and a ready message written to loggerHasExited. The runtime picks one at random (via the spec)

If one or more of the communications can proceed, a single one that can proceed is chosen via a uniform pseudo-random selection. Otherwise, if there is a default case, that case is chosen. If there is no default case, the "select" statement blocks until at least one of the communications can proceed.

6. If it chose the sub case, then then the message is written to the sub channel. The goroutine spawned in 2. wakes, goes to select, and exits on ctx.Done() without ever logging via tea.Printf.

Note that also, since the command itself is blocking, the select here blocks before going into selection, and does not close until sub is received, which leaks a goroutine if you Start() then immediately Close() the app.

from the same select spec:

For all the cases in the statement, the channel operands of receive operations and the channel and right-hand-side expressions of send statements are evaluated exactly once, in source order, upon entering the "select" statement. The result is a set of channels to receive from or send to, and the corresponding values to send. Any side effects in that evaluation will occur irrespective of which (if any) communication operation is selected to proceed. Expressions on the left-hand side of a RecvStmt with a short variable declaration or assignment are not yet evaluated.

In fact, I think since that example always tries to have an open waitForActivity goroutine running, it always leaks will tend to leak a goroutine.

[Adjective-Object]

Apologies for the wall of text. That example is analogous to my current solution, which runs the loop outside of tea. I've spent a lot of time digging through exit scenarios for it, and it will also drop a message and a leak a goroutine in a similar order of operations.

[Thunder33345]

I see the problem now, since there will be at least one waitForActivity hanging even if program is dead, there would always at least be one dropped message that will be consumed by the hanging routine before select will ignore the channel.

Thinking about the hanging routine gave me an idea, of using(or rather abusing) context.context specifically context.Done(), I decied to spend some time and play around with it.

1. the modal holds the context and the cancel function, when the modal quits, the cancel function is called before quitting
2. waitForActivity is altered into a select either from ctx.Done or the sub channel(to stop hanging)
3. the logger uses select case context.Done() to decide if it should fmt.Println() default to pass it into the sub channel

This seems to work fine most times at least, but due to point 2, when it is in a high volume application, there still is the possibility of dropped messages, in that case it's probably due to when both ctx.Done and sub having a message available, and the runtime randomly choosen to read from the sub channel instead. This solution is imperfect and also ugly(having to pass the same context everywhere) but it seems to be the best I could thought of, I dont think I have any other ideas.