SEM_UNLINK(3POSIX)

okay bestie, welcome to the POSIX Programmer's Manual πŸ’– β€” this page is literally SEM_UNLINK(3POSIX), and we're gonna talk about yeeting named semaphores into the void. slay.


🌸 PROLOG 🌸

so real talk before we start: this manual page is part of the POSIX Programmer's Manual. the Linux implementation of this interface may differ (so like, go consult the corresponding Linux manual page for the deets on Linux behavior), or honestly the interface might just not be implemented on Linux at all. πŸ™ˆ iykyk.


πŸ‘‘ NAME πŸ‘‘

sem_unlink β€” remove a named semaphore. that's it, that's the vibe. πŸ’…


πŸŽ€ SYNOPSIS πŸŽ€

#include <semaphore.h>

int sem_unlink(const char *name);

πŸ¦‹ DESCRIPTION πŸ¦‹

okay so here's the tea, bestie. the sem_unlink() function shall remove the semaphore named by the string name. periodt.

now, plot twist: if the semaphore named by name is currently referenced by other processes, then sem_unlink() shall have no effect on the state of that semaphore. like, it's not gonna yank the rug out from under anybody. 😌

and if one or more processes have the semaphore open when sem_unlink() gets called, destruction of the semaphore is postponed until all references to the semaphore have been destroyed by calls to sem_close(), _exit(), or exec. so it's giving "we'll deal with you later" energy. πŸ’€

calls to sem_open() to recreate or reconnect to the semaphore refer to a new semaphore after sem_unlink() is called. fresh start, new main character. ✨

and the part everyone worries about: the sem_unlink() call shall not block until all references have been destroyed β€” it shall return immediately. no waiting around, she's booked and busy. πŸƒβ€β™€οΈπŸ’¨


πŸ’– RETURN VALUE πŸ’–

upon successful completion, the sem_unlink() function shall return a value of 0. iconic behavior. 🫢

otherwise? the semaphore shall not be changed, and the function shall return a value of -1 and set errno to indicate the error. sad girl hours. 😭


πŸ’… ERRORS πŸ’…

the sem_unlink() function shall fail if:

  • EACCES β€” Permission is denied to unlink the named semaphore. rude, honestly.
  • ENOENT β€” The named semaphore does not exist. it's not there bestie, it never was. πŸ’€

the sem_unlink() function may fail if:

  • ENAMETOOLONG β€” the length of the name argument exceeds {_POSIX_PATH_MAX} on systems that do not support the XSI option, or exceeds {_XOPEN_PATH_MAX} on XSI systems. OR it has a pathname component that is longer than {_POSIX_NAME_MAX} on systems that do not support the XSI option, or longer than {_XOPEN_NAME_MAX} on XSI systems. too long, too much, overstimulated. 😭
heads up though: a call to sem_unlink() with a name argument that contains the same semaphore name as was previously used in a successful sem_open() call shall not give an [ENAMETOOLONG] error. so if it worked before, it works again. no cap. ✨

the following sections are informative. 🧚 (which is fancy speak for "not the actual rules, just lil notes")


🌈 EXAMPLES 🌈

None.


🌸 APPLICATION USAGE 🌸

None.


⭐ RATIONALE ⭐

None.


πŸ”₯ FUTURE DIRECTIONS πŸ”₯

a future version might require the sem_open() and sem_unlink() functions to have semantics similar to normal file system operations. so like... watch this space. πŸ‘€


🫢 SEE ALSO 🫢

  • semctl()
  • semget()
  • semop()
  • sem_close()
  • sem_open()

The Base Definitions volume of POSIX.1‐2017, <semaphore.h> β€” go read it, it's giving required reading. πŸ“š


Portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1-2017, Standard for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of Electrical and Electronics Engineers, Inc and The Open Group. In the event of any discrepancy between this version and the original IEEE and The Open Group Standard, the original IEEE and The Open Group Standard is the referee document. The original Standard can be obtained online at http://www.opengroup.org/unix/online.html .

Any typographical or formatting errors that appear in this page are most likely to have been introduced during the conversion of the source files to man page format. To report such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html .


okay that's the whole page bestie, we ate and left no crumbs πŸ’…βœ¨ this was brought to you by IEEE/The Open Group, dated 2017 β€” stay iconic, and remember: sem_unlink() never blocks, and neither should you. πŸŽ€πŸ’–πŸ¦‹