mirror of
https://github.com/mjl-/mox.git
synced 2024-12-26 08:23:48 +03:00
e943e0c65d
when broadcasting a change, we would try to send the changes on a channel, non-blocking. if we couldn't send (because there was no pending blocked receive), we would wait until the potential receiver would explicitly request the changes. however, the imap idle handler would not explicitly request the changes, but do a receive on the changes channel. since there was no pending blocked send on the channel, that receive would block. only when another event would come in, would both the pending and the new changes be sent. we now use a channel only for signaling there are pending changes. the channel is buffered, so when broadcasting we can just set the signal by a non-blocking send and continue with the next listener. the receiver will get the buffered signal. it can then get the changes directly, but lock-protected. found when looking at a missing/delayed new message notification in thunderbird when two messages arrive immediately after each other. this doesn't fix that problem though: it seems thunderbird just ignores imap untagged "exists" messages (indicating a new message arrived) during the "uid fetch" command that it issued after notifications from an "idle" command. |
||
|---|---|---|
| .. | ||
| account.go | ||
| account.html | ||
| account_test.go | ||
| accountapi.json | ||
| admin.go | ||
| admin.html | ||
| admin_test.go | ||
| adminapi.json | ||
| autoconf.go | ||
| autoconf_test.go | ||
| import.go | ||
| mtasts.go | ||
| mtasts_test.go | ||
| web.go | ||
| web_test.go | ||
| webserver.go | ||
| webserver_test.go | ||