Grokbase › Groups › Go › golang-nuts › August 2013
FAQ
I've been trying to figure out how to use Windows IO Completion Ports in
go, so I started looking at fsnotify <http://github.com/howeyc/fsnotify> for
examples.

As I was going through the code, I became confused once I got to theruntime.LockOSThread call in readEvents()<https://github.com/howeyc/fsnotify/blob/master/fsnotify_windows.go#L403>.
According to godoc, LockOSThread "wires the calling goroutine to its
current operating system thread. Until the calling goroutine exits or calls
UnlockOSThread, it will always execute in that thread, and no other
goroutine can." Since each fsnotify watcher spawns a goroutine that calls
the infinitely looping readEvents, I assume there must be at least one
thread per Watcher. (There must also be at least one other thread to
process the other goroutines in fsnotify.) What triggers the creation of
new threads for each of these readEvent goroutines?

Is there any documentation for the current go runtime's threading model? I
searched but had little success.

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Ian Lance Taylor at Aug 3, 2013 at 6:24 pm ⇧

    On Sat, Aug 3, 2013 at 11:10 AM, wrote:
    I've been trying to figure out how to use Windows IO Completion Ports in go,
    so I started looking at fsnotify for examples.

    As I was going through the code, I became confused once I got to the
    runtime.LockOSThread call in readEvents(). According to godoc, LockOSThread
    "wires the calling goroutine to its current operating system thread. Until
    the calling goroutine exits or calls UnlockOSThread, it will always execute
    in that thread, and no other goroutine can." Since each fsnotify watcher
    spawns a goroutine that calls the infinitely looping readEvents, I assume
    there must be at least one thread per Watcher. (There must also be at least
    one other thread to process the other goroutines in fsnotify.) What
    triggers the creation of new threads for each of these readEvent goroutines?
    The runtime automatically creates threads as needed.
    Is there any documentation for the current go runtime's threading model? I
    searched but had little success.
    I don't think there is any overall doc. The most recent overhauls
    were done by Dmitriy, with these design docs:

    https://docs.google.com/a/google.com/document/d/1TTj4T2JO42uD5ID9e89oa0sLKhJYD0Y_kqxDv3I3XMw/view

    https://docs.google.com/a/google.com/document/d/1ETuA2IOmnaQ4j81AtTGT40Y4_Jr6_IDASEKg0t0dBR8/view

    Ian

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dmitry Vyukov at Aug 3, 2013 at 6:49 pm ⇧

    On Sat, Aug 3, 2013 at 10:10 PM, wrote:
    I've been trying to figure out how to use Windows IO Completion Ports in go,
    so I started looking at fsnotify for examples.
    Note that net package uses IOCP for network IO under the hood. So you
    do not need to use IOCP for network IO.

    File IO and everything else do not use IOCP. However, file IO could
    use IOCP as well. I don't know why it does not. Probably nobody care
    enough to implement it.

    As I was going through the code, I became confused once I got to the
    runtime.LockOSThread call in readEvents(). According to godoc, LockOSThread
    "wires the calling goroutine to its current operating system thread. Until
    the calling goroutine exits or calls UnlockOSThread, it will always execute
    in that thread, and no other goroutine can." Since each fsnotify watcher
    spawns a goroutine that calls the infinitely looping readEvents, I assume
    there must be at least one thread per Watcher. Correct.
    (There must also be at least
    one other thread to process the other goroutines in fsnotify.) Correct.
    What
    triggers the creation of new threads for each of these readEvent goroutines?
    Go runtime automatically creates threads when (1) there is a goroutine
    that is able to run but not running and (2) there is less than
    GOMAXPROCS goroutines already running.
    Is there any documentation for the current go runtime's threading model? I
    searched but had little success.
    There are docs that Ian referenced.
    You can read src/pkg/runtime/proc.c, it is the goroutine scheduler
    implementation. It's a bit involved, though. Feel free to ask
    questions here if something is not clear.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedAug 3, '13 at 6:10p
activeAug 3, '13 at 6:49p
posts3
users3
websitegolang.org

3 users in discussion

Dmitry Vyukov: 1 post Applebyingram: 1 post Ian Lance Taylor: 1 post

Content

People

Support

Translate

site design / logo © 2022 Grokbase