FAQ
Hi,

I wanted to use system V / POSIX semaphores across a daemon written in go
and another in C. However I find that the syscall package does not include
any function related to that. Is it intentional? Is there any alternate way
to use them?

-Shubhro

--
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/d/optout.

Search Discussions

  • Marvin Stenger at Mar 29, 2016 at 9:10 am
    I guess you could make use of cgo. But I'm not sure, if that is the
    only/best way.

    Am Dienstag, 29. März 2016 10:34:15 UTC+2 schrieb Shubhro Sinha:
    Hi,

    I wanted to use system V / POSIX semaphores across a daemon written in go
    and another in C. However I find that the syscall package does not include
    any function related to that. Is it intentional? Is there any alternate way
    to use them?

    -Shubhro
    --
    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/d/optout.
  • Ian Lance Taylor at Mar 29, 2016 at 1:25 pm

    On Tue, Mar 29, 2016 at 2:09 AM, Marvin Stenger wrote:
    I guess you could make use of cgo. But I'm not sure, if that is the
    only/best way.
    Somebody could add support to the golang.org/x/sys/unix package.

    Ian
    Am Dienstag, 29. März 2016 10:34:15 UTC+2 schrieb Shubhro Sinha:
    Hi,

    I wanted to use system V / POSIX semaphores across a daemon written in go
    and another in C. However I find that the syscall package does not include
    any function related to that. Is it intentional? Is there any alternate way
    to use them?

    -Shubhro
    --
    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/d/optout.
    --
    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/d/optout.
  • Konstantin Khomoutov at Mar 29, 2016 at 1:42 pm

    On Tue, 29 Mar 2016 06:25:12 -0700 Ian Lance Taylor wrote:

    On Tue, Mar 29, 2016 at 2:09 AM, Marvin Stenger
    wrote:
    I guess you could make use of cgo. But I'm not sure, if that is the
    only/best way.
    Somebody could add support to the golang.org/x/sys/unix package.
    According to manual pages on my Linux system, 4 syscalls and
    accompanying data types cover the whole semaphores thing.

    So, this task appears to be tractable.

    --
    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/d/optout.
  • Sam Whited at Mar 29, 2016 at 3:39 pm

    On Tue, Mar 29, 2016 at 8:41 AM, Konstantin Khomoutov wrote:
    According to manual pages on my Linux system, 4 syscalls and
    accompanying data types cover the whole semaphores thing.

    So, this task appears to be tractable.
    If you're using existing semaphores created by another process this is
    true, but if you want to create your own semaphore you'll need to be
    able to call sem_open(3) (for named semaphores; there are other
    methods for closing, unlinking, creating unnamed semaphores, etc.).

    I assume this is what he's asking about, and it would probably make
    sense to stick something like that in x/sys/unix.

    —Sam

    A full list (I think?) would include:

    - sem_open(3)
    - sem_wait(3)
    - sem_post(3)
    - sem_close(3)
    - sem_unlink(3)
    - sem_init(3)
    - sem_destroy(3)

    --
    Sam Whited
    pub 4096R/54083AE104EA7AD3
    https://blog.samwhited.com

    --
    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/d/optout.
  • Konstantin Khomoutov at Mar 29, 2016 at 4:26 pm

    On Tue, 29 Mar 2016 10:39:01 -0500 Sam Whited wrote:

    On Tue, Mar 29, 2016 at 8:41 AM, Konstantin Khomoutov
    wrote:
    According to manual pages on my Linux system, 4 syscalls and
    accompanying data types cover the whole semaphores thing.

    So, this task appears to be tractable.
    If you're using existing semaphores created by another process this is
    true, but if you want to create your own semaphore you'll need to be
    able to call sem_open(3) (for named semaphores; there are other
    methods for closing, unlinking, creating unnamed semaphores, etc.).

    I assume this is what he's asking about, and it would probably make
    sense to stick something like that in x/sys/unix.

    —Sam

    A full list (I think?) would include:

    - sem_open(3)
    - sem_wait(3)
    - sem_post(3)
    - sem_close(3)
    - sem_unlink(3)
    - sem_init(3)
    - sem_destroy(3)
    No, the 3rd section of manual pages on Linux-based systems means
    facilities provided by libraries -- either libc or other user-space
    stuff. This means cgo. Go-specific code should strive to rely on
    system calls only; and for x/sys/unix it is, I assume, a must except
    we're talking about some "weird" platforms like Solaris (?) which must
    route all calls to the kernel through libc. On Linux-based systems,
    syscalls are described by the pages in the 2nd section, so here we go:

       ~% apropos semaphore | grep -F '(2)'
       semctl (2) - System V semaphore control operations
       semget (2) - get a System V semaphore set identifier
       semop (2) - System V semaphore operations
       semtimedop (2) - System V semaphore operations

    Quick googling reveals that indeed this appears to be a rather complete
    set of stuff to deal with semaphores.

    --
    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/d/optout.
  • Shubhro at Apr 15, 2016 at 5:06 am
    I ended up using syscall.Sycall() function to call the SYS V semaphore
    system calls and wrapped them up in a package.

    -Shubhro

    On Tuesday, March 29, 2016 at 9:56:42 PM UTC+5:30, Konstantin Khomoutov
    wrote:
    On Tue, 29 Mar 2016 10:39:01 -0500
    Sam Whited <s...@samwhited.com <javascript:>> wrote:
    On Tue, Mar 29, 2016 at 8:41 AM, Konstantin Khomoutov
    <flat...@users.sourceforge.net <javascript:>> wrote:
    According to manual pages on my Linux system, 4 syscalls and
    accompanying data types cover the whole semaphores thing.

    So, this task appears to be tractable.
    If you're using existing semaphores created by another process this is
    true, but if you want to create your own semaphore you'll need to be
    able to call sem_open(3) (for named semaphores; there are other
    methods for closing, unlinking, creating unnamed semaphores, etc.).

    I assume this is what he's asking about, and it would probably make
    sense to stick something like that in x/sys/unix.

    —Sam

    A full list (I think?) would include:

    - sem_open(3)
    - sem_wait(3)
    - sem_post(3)
    - sem_close(3)
    - sem_unlink(3)
    - sem_init(3)
    - sem_destroy(3)
    No, the 3rd section of manual pages on Linux-based systems means
    facilities provided by libraries -- either libc or other user-space
    stuff. This means cgo. Go-specific code should strive to rely on
    system calls only; and for x/sys/unix it is, I assume, a must except
    we're talking about some "weird" platforms like Solaris (?) which must
    route all calls to the kernel through libc. On Linux-based systems,
    syscalls are described by the pages in the 2nd section, so here we go:

    ~% apropos semaphore | grep -F '(2)'
    semctl (2) - System V semaphore control operations
    semget (2) - get a System V semaphore set identifier
    semop (2) - System V semaphore operations
    semtimedop (2) - System V semaphore operations

    Quick googling reveals that indeed this appears to be a rather complete
    set of stuff to deal with semaphores.
    --
    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/d/optout.
  • Tema Dudko at May 11, 2016 at 11:08 pm
    Can you share this package?
    Thanks

    вторник, 29 марта 2016 г., 11:34:15 UTC+3 пользователь Shubhro Sinha
    написал:
    Hi,

    I wanted to use system V / POSIX semaphores across a daemon written in go
    and another in C. However I find that the syscall package does not include
    any function related to that. Is it intentional? Is there any alternate way
    to use them?

    -Shubhro
    --
    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/d/optout.
  • Shubhro sinha at May 12, 2016 at 1:05 am
    https://github.com/shubhros/drunkendeluge/tree/master/semaphore

    -Shubhro
    On 12 May 2016 04:38, wrote:

    Can you share this package?
    Thanks

    вторник, 29 марта 2016 г., 11:34:15 UTC+3 пользователь Shubhro Sinha
    написал:
    Hi,

    I wanted to use system V / POSIX semaphores across a daemon written in
    go and another in C. However I find that the syscall package does not
    include any function related to that. Is it intentional? Is there any
    alternate way to use them?

    -Shubhro
    --
    You received this message because you are subscribed to a topic in the
    Google Groups "golang-nuts" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/golang-nuts/zpwbWye5o7o/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMar 29, '16 at 8:34a
activeMay 12, '16 at 1:05a
posts9
users7
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase