GoRoutine Scheduler Question

210 views
Skip to first unread message

John Souvestre

unread,
Sep 18, 2026, 2:00:01 AMSep 18
to golang-nuts

Hello.

 

I'm seeing a goroutine scheduling oddity that I don't understand.  Can anyone explain why this is?

 

I have a function which occasionally writes to a file.  I noticed that this was taking longer than I expected.  It was because I was also Sync'ing the file.  So I set up a goroutine just to do the sync, allowing the main function to continue.  I used a buffered channel to pass the file info to it.

 

       func initSyncFile() {

              go func() {

                     for {

                           file := <-syncFileQue

                           err := (file.fileH).Sync()

                           ...

                     }

              }()

       }

 

It executed ok, but I still saw a delay in the main function.  I'm guessing that the new goroutine was set up on the same fiber, and that the channel transfer resulted in it running, thus pausing my main function.  To avoid this, I added a "runtime.Gosched()" at the top of the sync function.  I was expecting this to pause the sync function, allowing the main function to run.  But there was no change.  Why?

 

Some additional info: I Then replaces the Gosched() with a Sleep(1 time.Second).  This worked!  The main function continued right away.  I found that this worked as long as the Sleep() was 5ms or longer.

 

I should note that this was on a Windows system.  I believe that 5ms is the clock rate.  I'm guessing that when the Sleep() is long enough, the reschedule takes place right away.

 

This solves my immediate problem.  But it leaves me wondering why Gosched() didn't cause the same result.

 

Thanks,

 

John

 

    John Souvestre    New Orleans LA, USA    504-454-0899

 

Jason E. Aten

unread,
Sep 18, 2026, 5:34:08 AMSep 18
to golang-nuts
I don't know for sure. It's hard to tell without a little reproducer to study. A couple of suggestions:

a) put timestamped prints in at all the critical places, to debug;

b) run under the profiling / execution tracing tools and see what they tell you;

and structurally

c) you could try passing the whole []byte to be written over a buffered channel to the writing goroutine. I don't think any operating system will let you write more bytes while an fsync is already in progress. so usually what people do is write everything for 2 seconds (or so) and then do one fsync; rather than one fsync per write. If there a 100 small writes per second, this saves you alot of slow fsyncs. Since it sounds like you don't need to wait until the fsync is finished to go on, this could be as simple as having a timer inside your writing goroutine that fires every 2 seconds and if there have been any []byte writes over the write channel, does the fsync.

John Souvestre

unread,
Sep 18, 2026, 11:09:00 AMSep 18
to Jason E. Aten, golang-nuts

Hi Jason.

 

  1. I did.  That’s how I was able to describe what happened.
  2. What would I be looking for that I don’t already know?
  3. An entire message is written to the file by the main function, before the channel is used to trigger the sync function.

 

John

 

    John Souvestre    New Orleans LA, USA    504-454-0899

 

--
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...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/e2be1a43-71a2-4364-8f01-7b24210d2124n%40googlegroups.com.

Def Ceb

unread,
Sep 18, 2026, 11:43:27 AMSep 18
to golang-nuts
So the issue is essentially that Sync() is stalling writes?
To the best of my knowledge, this is the expected behavior, and why buffering writes is so commonplace.

--
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...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/01c401dd4700%248904fb00%249b0ef100%24%40Souvestre.com.

Brian Candler

unread,
Sep 18, 2026, 12:26:03 PMSep 18
to golang-nuts
I think the question is why a Sync in one goroutine is stalling a different goroutine (or the entire program). But without a full reproducer we can't be sure. And it could be something Windows-specific.

John Souvestre

unread,
Sep 18, 2026, 7:12:30 PMSep 18
to Def Ceb, golang-nuts

No.  My question is about how the goroutine scheduling worked.

 

John

 

    John Souvestre    New Orleans LA, USA    504-454-0899

 

Brian Candler

unread,
Sep 18, 2026, 8:01:36 PMSep 18
to golang-nuts
On Friday, 18 September 2026 at 18:12:30 UTC+1 John Souvestre wrote:

No.  My question is about how the goroutine scheduling worked.

You might find these useful:

But it sounded like you'd observed some behaviour you weren't expecting. To get a definitive explanation, you should provide a standalone program that reproduces the issue.  Normally, calls which are expected to block at the OS level will run in their own thread.
Reply all
Reply to author
Forward
0 new messages