FAQ
Hey guys, I'm reading source code in package syscall now, and met some
problems:

Since I'm totally a noob of syscall, so don't hesitate to share anything
you know about it :)

First about func RawSyscall(trap, a1, a2, a3 uintptr) (r1, r2 uintptr, err
Errno) <http://golang.org/pkg/syscall/#RawSyscall> : what does its
parameter "trap, a1, a2, a3" & return value "r1 r2" means? I've searched
documents and this forum but seems lack of description about this.

Second, since I'm using darwin/amd64 I searched source code and find it
here:
http://golang.org/src/pkg/syscall/asm_darwin_amd64.s?h=RawSyscall

Seems it's written by assemble(which I can't understand), can you explain
what happened in line 61-80, and what's the meaning of "ok1:" part under
line 76?

I also found some code
in http://golang.org/src/pkg/syscall/zsyscall_darwin_amd64.go , what does
"zsyscall" mean in its filename? What's the difference between “syscall” &
“rawsyscall”? How and when to use them if I want to write my own syscall
function(Yes, os package gave many choices but there are still some
situation it doesn't cover)?

So many noob questions, thanks for your patience to read and answer :)

--
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Anthony Martin at Jun 7, 2013 at 8:43 am

    Reck Hou once said:
    First about func RawSyscall(trap, a1, a2, a3 uintptr) (r1, r2 uintptr, err
    Errno) <http://golang.org/pkg/syscall/#RawSyscall> : what does its
    parameter "trap, a1, a2, a3" & return value "r1 r2" means? I've searched
    documents and this forum but seems lack of description about this.
    Trap is the system call number. The other parameters correspond
    to the arguments expected by the system call, the result of the
    system call and the error code, if present.
    Second, since I'm using darwin/amd64 I searched source code and find it
    here:
    http://golang.org/src/pkg/syscall/asm_darwin_amd64.s?h=RawSyscall

    Seems it's written by assemble(which I can't understand), can you explain
    what happened in line 61-80, and what's the meaning of "ok1:" part under
    line 76?
    If you can't read assembly, you won't get far in .s files.
    This is a pretty simple procedure. It sets up the registers
    as expected by the system call. Performs the call and checks
    the result. If there as an error, it stores -1 in the first
    result parameter and the error code in the "err" result
    parameter (both on the stack). Otherwise, it stores the
    result from from the system call in the result parameters.

    The "ok1:" is just a label which frees the programmer from
    having to manually calculate jump PC offsets.
    I also found some code
    in http://golang.org/src/pkg/syscall/zsyscall_darwin_amd64.go , what does
    "zsyscall" mean in its filename? What's the difference between “syscall” &
    “rawsyscall”? How and when to use them if I want to write my own syscall
    function(Yes, os package gave many choices but there are still some
    situation it doesn't cover)?
    Filenames with a "z" prefix are automatically generated from other
    files. The difference between Syscall and RawSyscall is that the
    former will coordinate with the scheduler, allowing it to run any
    other goroutines while this one is potentially blocked in a system
    call. If you're absolutely certain your system call won't block,
    you can use RawSyscall.

    Cheers,
       Anthony

    --
    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 [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • Reck Hou at Jun 7, 2013 at 9:57 am
    Anthony:

    Thanks for your quick reply. So if I use RawSyscall in one of some go
    routines, other routines will be blocked as well while RawSyscall is
    blocking? Is that means programmers should use `Syscall` in non-blocking
    situations and `RawSyscall` in blocking situations?

    Furthermore, where can I find documents about a specific syscall like
    "SYS_FORK"? Assume I'm using Unix-like system.

    --
    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 [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ian Lance Taylor at Jun 7, 2013 at 1:07 pm

    On Fri, Jun 7, 2013 at 2:57 AM, Reck Hou wrote:
    Thanks for your quick reply. So if I use RawSyscall in one of some go
    routines, other routines will be blocked as well while RawSyscall is
    blocking? Is that means programmers should use `Syscall` in non-blocking
    situations and `RawSyscall` in blocking situations?
    Yes, if you call RawSyscall you may block other goroutines from
    running. The system monitor may start them up after a while, but I
    think there are cases where it won't. I would say that Go programs
    should always call Syscall. RawSyscall exists to make it slightly
    more efficient to call system calls that never block, such as getpid.
    But it's really ann internal mechanism.
    Furthermore, where can I find documents about a specific syscall like
    "SYS_FORK"? Assume I'm using Unix-like system.
    Run "man 2 fork".

    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 [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJun 7, '13 at 6:47a
activeJun 7, '13 at 1:07p
posts4
users3
websitegolang.org

People

Translate

site design / logo © 2023 Grokbase