text:
Cookie Usage
Colour Key
Sudden Death
Monthly Poll
Caption Comp
eMail Author
Photo Galleries
Design Lineage
Size Charts
Science / Tech
Maps / Politics
Site Guide
What's New
Caption comp
Monthly poll
Sudden death
The Deadly Years
Your View
Title :
The Deadly Years
Series :
The Original Series
Rating :
Overall Ep :
First Aired :
8 Dec 1967
Stardate :
Director :
Joseph Pevney
Year :
Writers :
David P. Harmon
Season Ep :
x 11
Main Cast :
James Doohan
Montgomery Scott
DeForest Kelley
Leonard H. McCoy
Walter Koenig
Pavel A. Chekov
Nichelle Nichols
Nyota Uhura
Leonard Nimoy
William Shatner
James T. Kirk
George Takei
Hikaru Sulu
Guest Cast :
Majel Barrett
Christine Chapel
Charles Drake
Commodore Stocker
Felix Locher
Robert Johnson
Sarah Mashall
Doctor Janet Wallace
Carolyn Nelson
Yeoman Doris Arkins
Eddie Paskey
Lieutenant Leslie
Beverly Washburn
Lieutenant Arlene Galway
Laura Wood
Elaine Johnson
Why the hell does Stocker send the ship straight into the Neutral Zone? Okay he's no Kirk, but I find it hard to believe that he is so incompetent that he doesn't know or care about the rules regarding trespass into the zone.
Great Moment :
The regular characters do a great job portraying old men in this episode, especially Shatner as an old Kirk.
Body Count :
There's one body at the outpost, although we don't see him die. One outpost member and one blueshirt die on screen on the Enterprise, one outpost member off screen.
Factoid :
The story is reused for the TNG episode: "Unnatual selection".
The script called for a sequence showing Kirk growing younger again as he ran from Sickbay to the bridge. However, with the episode running longer than expected it was cut for time.
This episode establishes that Kirk is 34 years old. From this and the presumptive date of the the original series episodes in the 2260s (chosen to be exactly 300 years after they were originally aired), Kirk's birth date of 2233 was established.
Walter Koenig felt that Chekov seemed to act much younger than normal in this episode, most notably reacting to finding a body by screaming and running in terror.
McCoy will, of course, appear in very aged form once more when he is seen in TNG's "Encounter at Farpoint".
The Enterprise arrives at Gamma Hydra IV to resupply the colony there. Kirk, Spock, McCoy, Scotty, Lieutenant Galway, and Chekov beam down, but they find one of the colonists dead, apparently a natural death due to old age - amazing since nobody on the colony were over thirty. Two living colonists reveal themselves, both also very elderly even though they claim to be in their twenties.
Beaming back to the ship Kirk decides to remain in orbit until they have solved the mystery. Several guests are aboard, including Commodore Stocker, Doris Atkins, and Doctor Janet Wallace, who is an old girlfriend of Kirk's. Stocker is concerned about remaining at the planet as he needs to reach Starbase 10 as soon as possible. Kirk promises to get him there as soon as he can, but is determined to find out what happened on Gamma Hydra IV first.
Spock determines that a rogue comet passed near to the planet some time ago, but sees no reason how it could have caused the ageing effect. Commodore Stocker again presses for the ship to go to Starbase 10, where the research facilities are much more complete than those on the Enterprise. Kirk again declines, and as he leaves the bridge he repeats an earlier command to maintain their orbit, apparently forgetting that he had already said it. In his quarters he calls Spock and asks him about the comet that passed the planet recently, not remembering that they had already discussed the matter.
Kirk heads to sickbay with a pain in his shoulder. He finds Galway there complaining that she is suffering from an odd hearing loss. McCoy finds Kirk suffering from arthritis, a symptom usually associated with ageing - and a moment later Scotty walks in, grey haired and wrinkled and looking twenty years older. It is evident that whatever happened on the Enterprise is now striking the landing party.
Investigation shows that all of the landing party are suffering from rapid ageing, except for Chekov. McCoy estimates the rate of ageing at thirty years a day, but has no idea what could have caused it. Spock notes that although he is not suffering from obvious physical symptoms he is experiencing memory and vision loss, and is increasingly uncomfortable with the temperature on the ship. He reasons that since Vulcans life far longer than Humans, the effects are slower in his case. But even so, everyone on the landing party will likely be dead within a week or so.
Kirk and Wallace talk, flirting with one another until Kirk realises that her now deceased husband was much older than her and wonders if her attraction to him might be based on his increasingly elderly appearance, or worse, out of pity. She denies this.
Extensive tests on Chekov do little more than irritate him whilst providing no answers. Meanwhile the landing party to age at a tremendous rate, increasingly affecting their performance. Kirk constantly forgets that he has given orders, and even dozes off in the Captain's Chair whilst on duty. Spock is able to determine that the comet did indeed cause the problem; gamma Hydra IV passed through the tail of the comet, exposing it to low levels of radiation. Kirk orders a report to Starfleet in Code 2, since he doesn't want the Romulans to be able to read it - but Uhura notes that the Romulans already broke Code 2 according to a bulletin from Starfleet, something Kirk forgot. He orders her to use Code 3 instead. Kirk becomes agitated as the crew is forced to point out his mistakes again and again.
McCoy is able to confirm Spock's theory about the radiation from the comet. However, it seems that none of the usual treatments for radiation exposure will work in this case. For now, there remains no treatment.
Commodore Stocker meets with Spock, pointing out that Kirk is no longer in a fit state to command the ship. He asks that Spock take command, but Spock notes that whilst he is less affected than the others he is still half Human and thus prone to the effects. Stocker demands a competency hearing for Kirk, which according to regulations Spock must do when the Captain is physically or mentally unfit.
In sickbay the landing party suffers from the first casualty when Galway dies of old age. McCoy notes that she had an increased metabolism and this probably aged her even faster than the others, but nobody has a lot of time left.
Spock conducts the competency hearing. It is obvious to everybody present that Kirk is unable to perform his duties, and his attempts to defend himself come across as hopelessly inadequate and rather pathetic. He is removed from command and Commodore Stocker assumes command as the senior officer present. Kirk argues that although of high rank a Starbase commander is just a paper-pusher with no ability to command a ship. Unfortunately Spock must point out that Kirk no longer has a voice in what happens to the ship, much to Kirk's pain.
In sickbay, they review the original landing once again. Spock notes that there was only one time when Chekov was not with them, when he went into the building and found the body. The experience was obviously quite shocking to him, and McCoy wonders if perhaps the extra adrenaline in his body may have protected him from the effects of the radiation. In the early days of the atomic age adrenaline was used as a radiation treatment, though it was replaced by hyronaline in time. It is their first solid lead on a potential treatment, and McCoy pursues it immediately.
Stocker sends the Enterprise to Starbase 10, as he has wanted to do all along. He decides to save some time by taking a short cut through the Romulan Neutral Zone, mistakenly thinking this is a minor risk. In fact a Romulan fleet quickly locates and attacks the Enterprise. Stocker, with no battle experience, is at a loss as to how to effectively counter the attack. He tries to contact the ships to signal his peaceful intentions, but the Romulans ignore the hails.
In sickbay Kirk insists that McCoy try his treatment out immediately, despite the potential danger. Given that they will all die soon anyway McCoy reluctantly agrees, and injects Kirk.
On the bridge Stocker decides that the ship has no choice but to surrender. Chekov claims that the Romulans will not be interested as they don't take prisoners. With disaster imminent a completely recovered Kirk strides onto the bridge and takes command. He orders Uhura to transmit a message to Starfleet in Code 2, ignoring her objections about the Romulans cracking the code. In the message he states that he feels he has no choice but to self-destruct his ship using the new Corbomite device, which will destroy not only the Enterprise but all matter within 200,000 kilometers, leaving a dead zone in space which all ships must avoid for at least the next four solar years. Decoding this, the Romulan ships retreat in anticipation of the blast and the Enteprise is able to escape at high warp.
With everybody now being treated successfully the crisis is over. Stocker assures Kirk that he only acted in what he thought was the best interest of the ship and crew. When Kirk notes that there's very little a Starbase can do that a Starship can't, Stocker candidly admits that he realises now just what a Starship can do... with the right man in command.
The whole premise of this episode boils down to seeing what would happen if the Enterprise crew got old. It's good fun to watch that, and the actors certainly do a pretty good job of it. They must have had a lot of fun playing with their characters like this, and it does make the episode worth watching overall.
Where it does fall down is in the various sci fi trappings and plot elements surrounding it. Radiation causing such a thing is, obviously, pretty absurd. Especially given that the only explanation of it, and of why it wasn't detected earlier, is that it's a very
low level
of radiation. Um, we're surrounded by low level radiation all the time. There's low level radiation in the room you are sitting in right now. It would have made a little more sense if they'd at least made it some new type of radiation with unpredictable effects or something. And the idea of adrenaline being an effective treatment for radiation is also kind of silly - and the silliness compounds greatly when the adrenaline repairs all the effects of the ageing too.
This is actually a common element in Trek - it's taken for granted that curing any condition will automatically reverse all of the effects of that condition. Of course that's nonsensical. We can suppose that adrenaline in some way neutralises the radioactive material everyone breathed in on the planet, I suppose. Silly, but okay. But the same adrenaline then causes their arthritis to completely reverse? Causes their hair to regain its colour, instantly? Causes their mental faculties to return to normal? It doesn't really bear thinking about.
And even if adrenaline could do all that, why isn't it an effective immortality drug for the Federation? McCoy effectively
cures the ageing process
in this episode! Why can't he just do that for people who aged normally?!
I suppose one can only explain this by saying that this wasn't normal ageing. The radiation just happened to produce effects that exactly mirrored ageing... and those effects were not damage to the body as such, but rather things that only remained in place because of the presence of the radiation. So once the radiation was removed, things went back to normal. Which... is all kind of contrived and stupid, frankly.
But in the end we can ignore that, because really the episode isn't about why they age so much as what the results of the ageing are.
Another silly trapping is Commodore Stocker. It's a staple of TOS that any official of the Federation or any command level officer who isn't Kirk is insane, incompetent, or at the very least unpleasant. Don't believe me? Take a look at Captain Garth, Captain Tracey, Ambassador Fox, Galactic High Commissioner Ferris, Federation Undersecretary of Agricultural Affairs Nilz Baris... the list goes on. In this case Stocker is, at least, not obviously evil or nasty. And he's actually right to be concerned with Kirk's performance, and right to insist that he be relieved of command. But the whole "let's go through the neutral zone" thing just pushes it too far. Sure, he's not got any experience with ship command, but how much experience do you really need for that decision? Can you imagine any person who happened to find themselves in charge of a NATO military unit during the cold war and decided "what the hell, we're in a hurry, let's take a short cut through Russia"? Even if that person was completely inexperienced? Hell, even a civilian would know better. It would have been nice to see them try and come up with a more plausible error he could have made for the climax of the episode.
Special Edition
The usual improved effects shots of the ship exterior, most apparently a far improved battle sequence for the Romulan battle.
© Graham & Ian Kennedy
Page views : 41,500
Last updated : 20 Jan 2023


text:
- Volvo Group
- Bengaluru, Karnataka
About our Circle
- Looking for members
1 Leader, 1 Member
Networks we're affiliated with
Networks connect groups of Circles and individuals that share a common location, company, affinity, industry, or interest area.
Join this Circle
We're always looking for new members. Join today to be a part of Lean In's global community.
How it works
Circles are small groups of women who come together—online or offline—for real talk and peer support.
Why join a Circle?
We all need a safe space for real talk, inspiration, and support. Right now, we need community more than ever.

subset: commoncrawl


text:
Medical Library
Exercise Articles
Pick a Body Area
Other ChoicesSystemic Treatments Exercises For Physicians Newsletters
Loading...Please Wait
Exercise Programs
Before you start any of our exercise programs, consult your therapist.
If you are having trouble viewing these PDF files, please download the latest version of Adobe Reader.
Available ProgramsNeck
- Middle Back Stretching Program
- Middle Back Strengthening Program
- Middle Back Strengthening with Resistive Bands
- Middle Back Strengthening with Therapeutic Ball
- Codman's Pendulum Exercises
- Rotator Cuff Strengthening Program
- Rotator Cuff Strengthening with Resistive Bands
- General Shoulder Strengthening Program
- General Shoulder Stretching Program
- Frozen Shoulder Stretching Program
- Abdominal Strengthening
- Advanced Abdominal Strengthening
- Abdominal Strengthening with Therapeutic Ball
- Stretch and Strengthen
- Low Back Strengthening
- Low Back Stenosis Program
- Lumbar Stabilization Program
- Sub-Acute Low Back Pain Program
- Knee Range of Motion Program
- Kneecap Pain Program
- Advanced Knee Strengthening Program
- Thigh Strengthening with Therapeutic Ball
- Adductor Stretches/Strengthening
- TFL/ITB Stretches
- Quadricep Stretches
- Hamstring Stretches
- Hip Flexor Stretch
- Standing Calf Stretching
- Ankle Range of Motion
- Plantar Fasciitis Program
- Ankle Sprain Program
- Achilles Tendinosis Program
- Throwing Strength Program
- Golf Stretching Program
- Golf Strengthening Program
- Skiing Preparation Program
Links: Neck : Shoulder : Back : Elbow : Wrist & Hand : Hip : Knee : Leg : Ankle & Foot
The information in this medical library is intended for informational and educational purposes only and in no way should be taken to be the provision or practice of physical therapy, medical, or professional healthcare advice or services. The information should not be considered complete or exhaustive and should not be used for diagnostic or treatment purposes without first consulting with your physical therapist, occupational therapist, physician or other healthcare provider. The owners of this website accept no responsibility for the misuse of information contained within this website.


text:
Fedora systemd Services
This document describes the guidelines for systemd services, for use and inclusion in Fedora packages.
Since systemd includes some concepts which are extensions of previous concepts, the following definitions may be useful:
- Service
A process or task executed and controlled by the init system (e.g. systemd).
- Traditional Service
A service which is explicitly started or stopped, either by the init system at boot or manually by a superuser. In systemd, one of several types of service controlled by a
- Activated service
A service that is not (or not necessarily) started explicitly by the user but start when certain other events happen or certain state becomes true.
- Socket-activated Service
A service which is waiting for traffic across a socket before activating. In systemd, controlled by a
- D-Bus service
A service which activates in response to a message from the D-Bus system bus.
- Unit file
The systemd equivalent of a SysV initscript.
Unit Files
Each package that contains software that wants/needs to start a traditional service at boot MUST have a systemd unit file.
Ideally, systemd unit files are reusable across distributions and shipped with the upstream packages. Please consider working with upstream to integrate the systemd files you prepare in the upstream sources. Information for developers on how to integrate systemd support best with their build system you may find in daemon(8).
Unit files for traditional services have a naming scheme of
When considering what basename to use,
keep in mind that we'd like to use the same service names for software across distributions.
We'd also like to ship the
.service files in the upstream packages.
These desires create a few guides for naming a unit file:
Follow upstream if they're already distributing a
.servicefile and it's not likely to conflict with other packages.
Look at packages in other distros or talk with the maintainers of those packages and upstream to try to come up with a common name.
Unit files should be named after the software implementation that they support as opposed to the generic type of software. So, a good name would be
apache-httpd.serviceand bad names would be
apache.serviceas there are multiple httpd implementations and multiple projects produced by the apache foundation.
For backwards compatibility
you may also want to create a symlink from an older, name to the new name.
In the above example, for instance,
Fedora has always used
httpd for the service.
When creating the new
apache-httpd.service file,
also create a symlink named
that points at
Then end users that are used to using
service httpd
will have it continue to work.
Basic format
.service file must begin with a
[Unit] section:
[Unit] Description=A brief human readable string describing the service (not the .service file!) Documentation=man:foo.service(8) man:foo.conf(5) https://www.foo.org/docs/
Description= line must not exceed 80 characters,
and must describe the service, and not the
.service file.
For example, "Apache Web Server" is a good description,
but "Starts and Stops the Apache Web Server" is a bad one.
Documentation field
Systemd has support for defining documentation in unit files
via the
Documentation= field.
System administrators will be looking at the contents of the
Documentation= field
to determine what the service is,
how to configure it,
and where to locate additional documentation relating to the service.
Accordingly, packagers are strongly encouraged
to include any available sources in the
Documentation= field
which provide this information.
If a man page or info page is present in the package,
refer to it using
man:manpage or
info:infofile respectively.
If the documentation is in plaintext, use
Lastly, if no local documentation exists in the package,
but it exists at a URL,
use the URL (with
https://) in this field.
Multiple URIs can be added to the
Documentation= field,
as a space separated list.
For details on URI definitions and formatting,
please refer to the
uri(7) manpage (
man uri).
Next, the
.service file must have a
[Service] section:
[Service] Type=... ExecStart=... ExecReload=...
Type= setting is very important.
For D-Bus services this should be
for traditional services
forking is usually a good idea,
for services not offering any interfaces to other services
simple is best.
For "one-shot" scripts
oneshot is ideal,
often combined with
See systemd.service(5)
for further discussion on the topic.
simple is the default type,
.service files which would normally set
may simply omit the
Type line altogether.
BusName= should be set for all services connecting to D-Bus.
(i.e. it is a must for those where
but might make sense otherwise, too)
Omit this option if your service does not take a name on the bus.
ExecStart= is necessary for all services.
This line defines the string that you would run to start the daemon,
along with any necessary options.
ExecReload= should be specified for all services supporting reload.
It is highly recommended to add code here
that synchronously reloads the configuration file here
/bin/kill -HUP $MAINPID is usually a poor choice,
due to its asynchronous nature).
Omit this option if your service does not support reloading.
Finally, the
.service file should have an
[Install] section:
[Install] WantedBy=...
The recommended parameters for
WantedBy= are either
graphical.target (services related to the graphical user interface)
multi-user.target (for everything else).
When the user (or our scriptlets) invoke
systemctl enable
the service will be set to start in these targets.
For more information regarding these options see systemd.unit(5) and systemd.service(5).
EnvironmentFiles and support for /etc/sysconfig files
EnvironmentFiles= line in the
[Service] section of
.service files
is used to support loading environment variables that can be used in unit files.
For instance,
if your sysv-initscript used a file in
/etc/sysconfig to set command line options,
you can use
EnvironmentFiles= like so:
[Service] Type=forking EnvironmentFile=-/etc/sysconfig/httpd ExecStart=/usr/sbin/httpd $OPTIONS ExecReload=/usr/sbin/httpd $OPTIONS -k restart
You may then refer to variables set in the
/etc/sysconfig/httpd file
${FOOBAR} and
in the
ExecStart= lines (and related lines).
${FOOBAR} expands the variable into one word,
$FOOBAR splits up the variable value at whitespace into multiple words)
- on the
EnvironmentFile= line
ensures that no error messages is generated
if the environment file does not exist.
Since many of these files were optional in sysvinit,
you should include the
- when using this directive.
Fields to avoid
For most services,
we do not want to use requirement dependencies in the
[Unit] section,
such as
Requires= or
Instead exclusively use ordering dependencies:
Before= and
This is used to implement loose coupling:
if someone asks two services to start at the same time,
systemd will properly order their startup
but not make it strictly necessary to run one if the other is started.
If you use a requirement dependency,
Wants= rather than
to make things a little bit more robust.
If you use a requirement dependency
in almost all cases you should also add an ordering dependency,
as ordering and requirement dependencies are orthogonal in systemd.
Here's an example of this common case:
A web application needs postgresql to store its data.
It is set to start
Afterpostgresql. On startup, the web application does not start until postgresql does.
Once running, the system administrator needs to restart postgresql due to a config tweak.
Since only
Afterwas used, the web application may be temporarily unable to serve some requests but it does not need to restart in order to serve pages after the database comes back up.
Avoid referring to
runlevelX.target units in all lines taking unit names
(such as
these are legacy names existing for compatibility with SysV only.
Names= (in the
[Unit] section).
Usually it is a better idea to symlink an additional name in the file system.
Note that a name listed in
Names= is only useful
when a service file is already loaded.
However, systemd loads only the service files actually referred to
in another loaded service,
and uses the filenames during the search.
Hence a name in
Names= is not useful as a search key,
but a symlink in the file system is.
Also do not put a (redundant)
Names=foobar.service line
into a file called
We want to keep our service files short.
Unit files should avoid using
StandardOutput= or
The default is the right choice for almost all cases,
and using the default allows users to change global defaults
in /etc/systemd/system.conf.
Systemd allows for the following forms of activated services: Hardware activation, Socket activation, Timer activation, and DBus activation.
Hardware activation
Hardware activation occurs when a service is installed
but only turns on if a certain type of hardware is installed.
Enabling of the service is normally done with a udev rule.
At this time we do not have further guidance on how to write those udev rules.
The service itself installs its
.service files in the normal places
and are installed by the normal systemd scriptlets. These services should never be enabled by the package
as they will be enabled by udev.
Socket activation
Socket activation occurs when a service allows systemd to listen for connections to a specific socket
and, when systemd receives a connection on that socket,
it starts the service.
To do this, the upstream source needs to have some minor coding work
to let systemd listen for connections on the socket
and there needs to be a
.socket file in
that tells systemd to listen to that socket
and what to start when a connection is received.
This is similar in function to inetd
and some, but not all, services coded to work with inetd
will work with socket activation.
However, socket activation can also be used to allow parallel startup of services.
If a service supports systemd socket activation as described above
and we additionally start it explicitly on boot,
then systemd will start it
but allow things that depend on it to startup at the same time.
If the dependent service makes a request to the socket activatable service before it has come up,
then systemd will cause the request to wait
until the socket activatable service has come up and can process the request.
To achieve this effect,
the service must be socket activatable as described above,
.service file for the service needs to have a
Wants= line for the
and the service must autostart.
Note that certain socket activated services
(notably network listening ones)
require FESCo approval —
see Default Services for details.
Once you have permission,
you can package the
.socket file
and use the systemd scriptlets that enable the service by default.
You need to also check the
.service file
to make sure it has a
Wants= entry on the
.socket file
as that ensures that starting the service will also inform systemd of the socket.
Timer activation
All packages with timed execution which already depend on systemd (for example because they contain systemd units) must use timer units instead of cron jobs, with no dependency or requirements on a crontab.
Packages which do not already depend or require systemd must not use timer units but instead depend and have requirement on crontabs, to avoid introducing unnecessary new dependencies on systemd directly.
DBus activation
In order to allow parallel startup of a D-Bus service and its consumers
it is essential that D-Bus services can be bus activated
and the D-Bus activation request is forwarded from the D-Bus system bus to systemd
so that you end up with only a single instance of the service,
even if a service is triggered by both boot-up and activation.
If historically your D-Bus service was not bus-activated
but started via a SysV init script,
it should be updated to use bus activation.
This may be implemented
by dropping a D-Bus
.service file in
and use the
SystemdService= directive therein
to redirect the activation to systemd.
Here's an example for a D-Bus bus-activable service.
The ConsoleKit bus activation file
[D-BUS Service] Name=org.freedesktop.ConsoleKit Exec=/usr/sbin/console-kit-daemon --no-daemon User=root SystemdService=console-kit-daemon.service
And the matching systemd unit file /usr/lib/systemd/system/console-kit-daemon.service:
[Unit] Description=Console Manager [Service] Type=dbus BusName=org.freedesktop.ConsoleKit ExecStart=/usr/sbin/console-kit-daemon --no-daemon
As you can see
SystemdService= is used in the D-Bus activation file
to bind the systemd service to the D-Bus service.
Traditionally, bus activated D-Bus services could not be disabled without uninstalling them entirely. systemd allows you to disable services by making D-Bus invoke an alias systemd service name (that can be created or removed to enable/disable activation) as an intermediary for the real service.
You can easily implement disabling
by directing the D-Bus service to an alias name of the real service file
(in the filesystem this shows up as a symlink
placed in
/etc/systemd/system to the real service file).
This alias is then controlled via
systemctl enable and
systemctl disable.
It is a good idea
(though technically not necessary)
to name this alias name after the D-Bus bus name of the service,
prefixed with
Example for Avahi, a service that the admin might need to disable:
instead of
SystemdService=avahi-daemon.service in the D-Bus activation file,
and then make
dbus-org.freedesktop.Avahi.service an optional alias of avahi-daemon.service
that can be controlled via the
Alias= directive
in the
[Install] section of the systemd service file.
This directive is then read by
systemctl enable and
systemctl disable
to create resp. remove a symlink
to make the service available resp. unavailable under this additional name.
A full example for the Avahi case:
Here is the D-Bus .service file for Avahi
[D-BUS Service] Name=org.freedesktop.Avahi SystemdService=dbus-org.freedesktop.Avahi.service # This service should not be bus activated if systemd isn't running, # so that activation won't conflict with the init script startup. Exec=/bin/false
Here is the Avahi systemd unit
.service file
[Unit] Description=Avahi mDNS/DNS-SD Stack Requires=avahi-daemon.socket [Service] Type=dbus BusName=org.freedesktop.Avahi ExecStart=/usr/sbin/avahi-daemon -s ExecReload=/usr/sbin/avahi-daemon -r NotifyAccess=main [Install] WantedBy=multi-user.target Also=avahi-daemon.socket Alias=dbus-org.freedesktop.Avahi.service
Alias= line ensures
that the existance of the
/etc/systemd/system/dbus-org.freedesktop.Avahi.service symlink
can be controlled by
systemctl enable and
systemctl disable.
Note that the creation/removal of the alias symlinks
should be done with
systemctl enable and
systemctl disable only.
You should not create these symlinks manually.
In general, it is also recommended to supply native systemd units for all services that are already bus activatable, so that these services can be controlled and supervised centrally like any other service with tools such as systemctl. A similar logic like the one shown above should apply.
See the D-Bus documentation for more information about bus activation: https://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-starting-services
Automatic restarting
If you package a long-running service, please consider enabling systemd's automatic restart feature for it, to improve reliability by making sure the system automatically attempts recovering a failing daemon. Please use
[Service] ... Restart=on-failure
[Service] ... Restart=on-abnormal
in your unit's
.service file for this.
The former will tell systemd to restart the daemon as soon as it fails
regardless of the precise reason.
It's a good choice for most long-running services.
Some daemons require a way to escape constant restarting
by exiting with any non-zero exit code.
For those services use
which will still restart the daemon when it fails "abnormally",
on unclean signal,
core dump,
or watchdog exits,
but not on unclean exit codes.
It is recommended to to enable automatic restarts for all long-running services,
but which setting is the right one,
and whether it is useful at all
depends on the specific service.
Please consult the
systemd.service(5) man page
for more information on the various settings.
Private devices and networking
If you package a long-running system service,
please consider enabling systemd's
PrivateDevices= and
PrivateNetwork= settings for it,
in order to improve security and minimize the attack surface.
PrivateDevices=yes is set in the
[Service] section
of a systemd service unit file,
the processes run for the service will run in a private file system namespace
/dev is replaced by a minimal version
that only includes the device nodes
as well as the submounts
and the
/dev/stdin symlinks.
No device nodes for physical devices will be included, however.
Furthermore, the CAP_MKNOD capability is removed.
Finally, the
devices cgroup controller is used
to ensure that no access to device nodes except the listed ones is possible.
This is an efficient way to take away physical device access for services,
thus minimizing the attack surface.
PrivateNetwork=yes is set in the
[Service] section
of a systemd service unit file,
the processes run for the service will run in a private network namespace
whith a private loopback network interface,
and no other network devices.
Network communication between host and service can not be initiated.
This is an efficient way to take away network access for services,
thus minimizing the attack surface.
By default both switches default to
Note that
PrivateDevices=yes should not be used for:
Services that actually require physical device access
Services which may be used to execute arbitrary user or administrator supplied programs (such as cron, …). We shouldn't limit what people can do with these services.
This option creates a new file system namespace where mount/umount propagation is turned off back into the host. This means that mounts made by the service will stay private to the service. Thus this option should not be used by services which shall be able to establish mounts in the host.
Note that
PrivateNetwork=yes should not be used for:
Services that actually require network access (with the exception of daemons only needing socket activation)
Services which may be used to execute arbitrary user or administrator supplied programs. (see above)
Services which might need to resolve non-system user and group names. Since on some setups resolving non-system users might require network access to an LDAP or NIS server, enabling this option on might break resolving of these user names. Note however that system users/groups are always resolvable even without network access. Hence it is safe to enable this option for daemons which just need to resolve their own system user or group name.
This also disconnects the AF_UNIX abstract namespace from the host (In case you wonder what this refers to: sockets listed in
/proc/net/unixthat start with an
@are in the abstract namespace, those which start in
/are in the file system namespace). This means that services which listen or connect to AF_UNIX sockets in the abstract namespaces might break. AF_UNIX sockets in the file system continue to work correctly even with
PrivateNetwork?=yes. We strongly recommend anyway to stop using abstract namespace AF_UNIX sockets, as they bring very little benefit these days. If your package uses them please consider moving them into the file system into a subdirectory in
/run(system services) or
$XDG_RUNTIME_DIR(user services).
This also disconnects the AF_NETLINK and AF_AUDIT socket families from the host. For services requiring auditing, that need to subscribe to network configuration changes, or want to subscribe to hardware devices coming and going (udev)
PrivateNetwork?=yescannot be used hence.
For further details see the systemd.exec(5) man page.
Filesystem locations
Packages with systemd unit files must put them into
%{_unitdir} evaluates to
/usr/lib/systemd/system on all Fedora systems
%{_userunitdir}% evaluates to
Unit files are architecture independent
(hence, not
and needed early in the boot process.
Most systemd service files should use
However, if the service runs as part of a user session
(e.g. pipewire services, gpg-agent, tracker, etc),
%{_userunitdir} instead.
Please note that in order for the
%{_unitdir} or
%{_userunitdir} macro to exist,
your package must have:
BuildRequires: systemd-rpm-macros
Unit files in spec file scriptlets
Information on proper handling of unit files in spec file scriptlets can be found here: Scriptlets#Systemd.
tmpfiles.d is a service provided systemd for managing temporary files and directories for daemons. For more information on how to use Tmpfiles.d in Fedora Packages, please see: Tmpfiles.d.
Why don't we….
Start the service after installation?
Installations can be in changeroots, in an installer context, or in other situations where you don't want the services autostarted.
Want to help? Learn how to contribute to Fedora Docs ›


text:
Your cart is empty!
Bright Vacuum Fluorescent Display (VFD)This digital bench scale has a fancy VFD display with bright blue digits so your weight readings will be nice and clear. Benefits of the VFD compared to LCD are a wider range of viewing angles, brighter digits, better contrast and easy viewing from greater distances.
IP 65 Water Resistant PlatformThe HW-100KGV bench scale has a water resistant housing with an IP (Ingress Protection) rating of 65. This means the HW-100KGV is protected from dust and low pressure water jets from all directions, as well as, corrosion, sleet, rain and more. So, if ya want to spay off this washdown scale when it gets dirty, go right ahead.
Checkweighing FeatureTo make sure ya get your weights just right, this bench scale has a checkweighing feature that will let ya set your target weight. Once your target weight is set, the HW-100KGV will let ya know when you're over, under or just right.
Accumulate ModeThis cumulative weighing feature will let ya get the weights of separate items, then ya can see the total weight of all the items ya just weighed. This is gonna come in real handy for getting separate items and total weights for your applications.
Does This Thing Count?You bet it does! All ya need to do is weigh a sample amount of pieces, so the HW-100KGV can know how much each piece weighs, then start counting. You'll be finished in no time.
Stainless Steel PlatformThe HW-100KGV has a durable stainless steel weighing platform to make cleanup a breeze. Stainless steel is great because it doesn't scratch easily and keeps its shine without rusting or tarnishing.
Tare FeatureThe tare button on the front of this washdown scale can be pressed to "zero out" the weight on the scale. You can then add more weight, and the display will only show the weight of the items you're adding. This sure is useful when ya want to use an expansion scoop to weigh your things, or if ya want to get separate weights of multiple items.
Liquid Level IndicatorThis very handy feature will help ya quickly and easily get your scale nice and level. A level scale is important for getting the most accurate weight readings.
2 YEAR MANUFACTURER'S WARRANTY!The A&D HW-100KGV is covered with a two year warranty from AND Weighing against defects in material and workmanship.
A&D TB:662 Replacement Power Adapter
A&D FT:10 Non-Skid Foot
A&D FG-01 Display Wall Mount
A&D AX-USB-2920-DIN DIN to USB Converter
A&D AD-8920A Remote Display
A&D HVW-17LSC (1) Castor


text:
Welcome to our website. If you continue to browse and use this website, you are agreeing to comply with and be bound by the following terms and conditions of use, which together with our privacy policy govern Boisterous Equipment's relationship with you in relation to this website. If you disagree with any part of these terms and conditions, please do not use our website.
The term 'Boisterous Equipment' or 'us' or 'we' refers to the owner of the website whose registered office is 3/14 Rose Street, Bunbury, WA, 6230, Australia. Our ABN is 11 619 839 468. The term 'you' refers to the user or viewer of our website.
The use of this website is subject to the following terms of use:
When you provide any details to us, your data is saved securely in our database and is not released to anybody else, ever. You can contact us at any time to request what information we have about you. When you order with us via credit card, your card details are sent via secure connection to the Braintree Payment Gateway, which securely connects with your bank and processes the order.


text:
|Australia Norwegian Forest Cat Rescue
|Norwegian Forest Cat Rescue Groups
|New Location ▼
|Change Breed ▼
|Find a Home for an Animal ▼
|Rescue Alerts ▼
|Donate to Norwegian Forest Cat Rescue as a gift or memorial, and we will mail a free acknowledgement card within 24 hours.
908 Norwegian Forest Cats have been adopted on Rescue Me!
|No Norwegian Forest Cat for adoption in Australia, please click 'New Location' above.
|PIease Read Before Adopting a Norwegian Forest Cat in Australia
Norwegian Forest Cats can make good pets in Australia if they match your IifestyIe. The Norwegian Forest Cat is a fluffy, long haired breed. Norwegian Forest Cats can be very loving and sociable. Norwegian Forest Cats will seek out human company if they are left alone. Norwegian Forest Cats are mellow and adaptable. This breed does very well with children. Many Norwegian Forest Cats get along well with other pets. Norwegian Forest Cats enjoy the outdoors, especially in cold weather.
Rescue Me! - HeIpingAnimaIs in Need.
|♥ This page is in fond memory of these Norwegian Forest Cats who are no longer with us... ♥
If you have experienced the loss of a beloved pet, or if you know someone who has... [POST A MEMORIAL HERE]
|Help Spread the Word! Please link to Australia Norwegian Forest Cat Rescue from your website.
Rescue Me! Website
Follow @RescueMeOrg
Norwegian Forest Cat Page
Follow @ForestCatRescue


text:
Trade Apprentice
Trade Apprentice Jobs 2023 across India for Freshers and Experienced Trade Apprentice Job Seekers instantly updated here on December 9, 2023. Discover all current Trade Apprentice vacancy for your qualification and here you can find active openings of Trade Apprentice Jobs 2023 in your Location. Check all details here and Apply online for latest top Full-time, Part-time Trade Apprentice 2023 across India. Explore upcoming Trade Apprentice Jobs 2023 in various Government sectors, now.Last Modified: Jan 07, 2023
1 Trade Apprentice Jobs 2023 updated on 9th Dec 2023
|Company Name
|Job Title
|Last Date
|Additional Superintendent Of Police
|11 Vacancies
|Any Bachelors Degree
Why Should I get placed in Trade Apprentice Jobs 2023?
There has been a huge demand for government jobs amongst the job hunters. Concurrently, there are various vacancies available in multiple sectors of Indian Government. Job seekers may feel difficulties in receiving latest government jobs notifications releasing by the Indian government. Nowadays, there are various options are available to check latest government jobs and Hirelateral is the one amongst those to alert job seekers about recent notifications which are released by the Indian government. Aspirants can get to know various Trade Apprentice job opportunities with additional information in this article.
How to get recent Trade Apprentice Jobs Notifications 2023?
We all know that the Indian government is gradually releasing Trade Apprentice Jobs 2023 for job seekers. We Hirelateral acts as a medium to provide the latest government jobs to the job hunters in an instant. We provide Trade Apprentice Jobs 2023 with additional information such as education, age limit, selection procedure, application/exam fee, pay scale, apply procedure, important dates and links, notification PDF, and so on. Job seekers who are interested to grab Trade Apprentice Jobs 2023 can check the latest news for the same in this page. We provide the latest information related to Trade Apprentice Jobs in the way you want. You can read the job description of a particular job and apply for the same without any trouble. Let's read below to know more about Trade Apprentice Jobs.
Where to get Trade Apprentice Jobs 2023 updates for free?
Are you tired of searching Trade Apprentice Jobs? Wanted to know the best source to check recent updates of Trade Apprentice Jobs 2023? If so, you have come to the right place. This page lists out the latest Trade Apprentice Jobs with detailed information such as job title, vacancy, eligibility, last date, and so on. Additionally, we provide useful resources such as syllabus, previous year question papers to the users to get ready for further rounds which will be conducted by the specified authorities. Candidates who are seeking for latest Trade Apprentice Jobs 2023 can get all information at one place. We update information related to Trade Apprentice Jobs once it is released by the officials at their official website. Check for latest Trade Apprentice Jobs 2023 updates on this page.
Why is Hirelateral for Latest Trade Apprentice Jobs 2023?
Apply for latest Trade Apprentice Jobs in all over India through Hirelateral.com. Get latest and upcoming job openings in Bangalore, Chennai, Pune, Hyderabad, Delhi, and Ahmedabad and nearby locations. We are providing the latest job openings for both fresher's and experienced candidates. Get all recent Trade Apprentice walk-ins, internships, upcoming Trade Apprentice job openings across India. Hirelateral updates all latest Trade Apprentice Job notifications with more information like educational qualification, total vacancy, eligibility criteria, job location, salary, apply procedure, selection process, last date to apply, and so on. Grab your dream job from the available number of job openings in various categories. Hirelateral helps the job aspirants in finding the best opportunities for various qualifications without any trouble.
How to Apply for Latest and Upcoming Trade Apprentice Jobs 2023?
We provide various Trade Apprentice job openings available in all over India with more information. Job seekers who are looking for the best Trade Apprentice Job opportunities can visit Hirelateral.com to find the suitable jobs for them. It's very simple to apply for Trade Apprentice Jobs by following the simple steps given below,
- At first, visit the hirelateral.com and check for the recent Trade Apprentice job updates in this page.
- Click on the desired Trade Apprentice Job openings that you want to apply.
- Read all the details mentioned such as eligibility, selection procedure, salary, and so on.
- If you're eligible to apply for the latest Trade Apprentice Job openings, click on the apply link or download the application form.
- Fill in the required fields and cross-check the entered information before submitting the form.
- Upload your documents, signature, and photographs if needed.
- Pay the application fee if any.
- Take a printout of the filled application for further use.
Get all recent Trade Apprentice Job updates at Hirelateral for free
Apply for various Trade Apprentice Jobs online or offline at hirelateral.com. Check for recent Trade Apprentice Job openings for both fresher's and experienced candidates here. Moreover, you can find the latest Trade Apprentice Job vacancies along with the preparation materials to prepare for the exam. You can also read interview tips here to face the personal interview. We update our website on a regular basis with the latest Trade Apprentice Job vacancies available in various locations. Stay tuned with us for more updates on latest Trade Apprentice Jobs across India. Subscribe to our email job alert to receive instant updates of all Trade Apprentice Government jobs in India. Get full details of Trade Apprentice jobs such as eligibility, vacancy, selection and application process, and much more at Hirelateral.com for free.


text:
Hawaiian Sugarcane Nanahu Plant, Thick stalks that are so deep purple in color they almost appear black contradict the eruption of new canes that are light green covered with a fine white powdery exterior. Sugarcane has been traded and sold around the globe for thousands of years and finally now available for you, the gardener to grow and enjoy for seasons to come. Simply plant in ground or even better in 18 to 24 inch planters so you can enjoy sugarcane on your patio or indoors year round. These are very healthy plants with well established root systems.
The growth rate and yield of Hawaiian Sugarcane Nanahu will vary greatly depending on soil type, sunlight, temperature and other factors. Lower leaves are trimmed and plants are topped to 36″ overall prior to shipping to reduce transpiration and travel stress.
Hawaiian Sugarcane Nanahu are very easy to grow plants that require little care. They add a tasty accent to any outdoor space, garden or patio. In very cold zones a containerized plant can be brought inside for the winter months. In the northern end of their grow zone Hawaiian Sugarcane Nanahu plants should be brought indoors or protected with mulch during the winter months.
When you receive your new Hawaiian Sugarcane Nanahu plant, there is no need to worry about planting right away. Your new plant can be stored for a while by simply placing it in a bucket with about a half inch of water in the bottom and moving it to a shady location. You can then add some mulch to the bucket to keep your plant standing upright. The mulch will also supply nutrients while in storage. This will give you plenty of time to select the ideal location for your new plant.
Hawaiian Sugarcane Nanahu grow very well in patio containers. Allow enough room for growth generally a 18″ to a 24″ diameter, 10″ deep container will suffice. Remember the looser the roots, the taller and healthier your plant will be. When the plant becomes root bound its growth will slow. At that point it is time for a larger pot.
Hawaiian Sugarcane Nanahu enjoys well drained but moist, rich organic mix. Remember try to stay away from wet, mucky or dry, sandy soils.
To help establish your new Hawaiian Sugarcane Nanahu Plant, fertilize sparingly at least 6 inches away from the base, monthly with a slow time release fertilizer. Unfertilized they will tend to grow very slowly. Note: The heavy salts in cheaper fertilizers will damage the roots and possibly kill the plant.
Best outdoors if grown in zone 9-11, find your zone here. This plant requires 80-100% sunlight. Depending on your location full sun is best. At the northern end of their grow zone Hawaiian Sugarcane Nanahu plants should be brought indoors or protected during the winter months. The patio zone is 4a-9b which means the potted plant will flourish over the summer months in colder zones but must be brought inside before harsh winter temps.
Here at the nursery, these Hawaiian Sugarcane Nanahu are grown under 20-40% shade cloth. If you plant directly in full sun you may experience leaf burn. It is best to acclimate This plant to its environment by keeping it outside and slowly moving it into a sunny area over a week or two to avoid stress before planting.
All Hawaiian Sugarcane Nanahu plants for sale will vary in size. In the spring, plants are often smaller than plants shipped in the fall. Plants designated with a sku ending in -4, or -6 will arrive in a standard 4 inch or 6 inch growers pot respectively. Our new, reusable, recyclable deep cells are 5 to 7 inches deep and 1 to 2.5 inches in diameter. Plants growing in these cells are easy to transplant and allow for deeper, faster growth and are designated with a -5, or -7. (Note: The item sku number can be found just below the buy button.) The color and style of these pots may vary. If we are out of a particular size item, we may ship a larger size at no additional charge.
Note: Before leaving, Hawaiian Sugarcane Nanahus are inspected, watered, pruned and topped to 36″ if necessary, to facilitate shipping. Your new Hawaiian Sugarcane Nanahus' pot is then bagged to ensure that the soil stays in the pot and not loose in the box. Then your plant is tissue or kraft paper wrapped and secured in place with natural biodegradable peanuts. You will be pleased.
You may want to buy Hawaiian Sugarcane Nanahu online now while they are in stock.


text:
A NIF library contains native implementation of some functions of an Erlang module. The native implemented functions (NIFs) are called like any other functions without any difference to the caller. Each NIF must also have an implementation in Erlang that will be invoked if the function is called before the NIF library has been successfully loaded. A typical such stub implementation is to throw an exception. But it can also be used as a fallback implementation if the NIF library is not implemented for some architecture.
Use this functionality with extreme care!
A native function is executed as a direct extension of the native code of the VM. Execution is not made in a safe environment. The VM can not provide the same services as provided when executing Erlang code, such as preemptive scheduling or memory protection. If the native function doesn't behave well, the whole VM will misbehave.
A native function that crash will crash the whole VM.
An erroneously implemented native function might cause a VM internal state inconsistency which may cause a crash of the VM, or miscellaneous misbehaviors of the VM at any point after the call to the native function.
A native function that do lengthy work before returning will degrade responsiveness of the VM, and may cause miscellaneous strange behaviors. Such strange behaviors include, but are not limited to, extreme memory usage, and bad load balancing between schedulers. Strange behaviors that might occur due to lengthy work may also vary between OTP releases.
The NIF concept is officially supported from R14B. NIF source code written for earlier experimental versions might need adaption to run on R14B or later versions:
- No incompatible changes between R14B and R14A.
- Incompatible changes between R14A and R13B04:
- Environment argument removed for
- Character encoding argument added to
- Module argument added to
enif_open_resource_typewhile changing name spaces of resource types from global to module local.
- Environment argument removed for
- Incompatible changes between R13B04 and R13B03:
- The function prototypes of the NIFs have changed to expect
argvarguments. The arity of a NIF is by that no longer limited to 3.
enif_get_datarenamed as
enif_make_stringgot a third argument for character encoding.
- The function prototypes of the NIFs have changed to expect
A minimal example of a NIF library can look like this:
/* niftest.c */ #include "erl_nif.h" static ERL_NIF_TERM hello(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]) { return enif_make_string(env, "Hello world!", ERL_NIF_LATIN1); } static ErlNifFunc nif_funcs[] = { {"hello", 0, hello} }; ERL_NIF_INIT(niftest,nif_funcs,NULL,NULL,NULL,NULL)
and the Erlang module would have to look something like this:
-module(niftest). -export([init/0, hello/0]). init() -> erlang:load_nif("./niftest", 0). hello() -> "NIF library not loaded".
and compile and test something like this (on Linux):
$> gcc -fPIC -shared -o niftest.so niftest.c -I $ERL_ROOT/usr/include/ $> erl 1> c(niftest). {ok,niftest} 2> niftest:hello(). "NIF library not loaded" 3> niftest:init(). ok 4> niftest:hello(). "Hello world!"
A better solution for a real module is to take advantage of the new directive on_load to automatically load the NIF library when the module is loaded.
A NIF does not have to be exported, it can be local to the module. Note however that unused local stub functions will be optimized away by the compiler causing loading of the NIF library to fail.
A loaded NIF library is tied to the Erlang module code version that loaded it. If the module is upgraded with a new version, the new Erlang code will have to load its own NIF library (or maybe choose not to). The new code version can however choose to load the exact same NIF library as the old code if it wants to. Sharing the same dynamic library will mean that static data defined by the library will be shared as well. To avoid unintentionally shared static data, each Erlang module code can keep its own private data. This private data can be set when the NIF library is loaded and then retrieved by calling enif_priv_data.
There is no way to explicitly unload a NIF library. A library will be automatically unloaded when the module code that it belongs to is purged by the code server.
As mentioned in the warning text at the beginning of this document it is of vital importance that a native function does return relatively fast. It is hard to give an exact maximum amount of time that a native function is allowed to work, but as a rule of thumb a well behaving native function should return to its caller before a millisecond has passed. This can be achieved using different approaches. If you have full control over the code that are to execute in the native function, the best approach is to divide the work into multiple chunks of work and call the native function multiple times. Function enif_consume_timeslice can be used this facilitate such work division. In some cases, however, this might not be possible, e.g. when calling third party libraries. Then you typically want to dispatch the work to another thread, return from the native function, and wait for the result. The thread can send the result back to the calling thread using message passing. Information about thread primitives can be found below. If you have built your system with the currently experimental support for dirty schedulers, you may want to try out this functionality by dispatching the work to a dirty NIF, which does not have the same duration restriction as a normal NIF.
All functions that a NIF library needs to do with Erlang are performed through the NIF API functions. There are functions for the following functionality:
Any Erlang terms can be passed to a NIF as function arguments and
be returned as function return values. The terms are of C-type
and can only be read or written using API functions. Most functions to read
the content of a term are prefixed
enif_get_ and usually return
true (or false) if the term was of the expected type (or not).
The functions to write terms are all prefixed
enif_make_ and usually
return the created
ERL_NIF_TERM. There are also some functions
to query terms, like
enif_is_identical and
All terms of type
ERL_NIF_TERM belong to an environment of type
ErlNifEnv. The lifetime of a term is
controlled by the lifetime of its environment object. All API functions that read
or write terms has the environment, that the term belongs to, as the first
function argument.
Terms of type binary are accessed with the help of the struct type
that contains a pointer (
data) to the raw binary data and the length
size) of the data in bytes. Both
data and
size are
read-only and should only be written using calls to API functions.
Instances of
ErlNifBinary are however always allocated by the user
(usually as local variables).
The raw data pointed to by
data is only mutable after a call to
enif_alloc_binary or
All other functions that operates on a binary will leave the data as read-only.
A mutable binary must in the end either be freed with
or made read-only by transferring it to an Erlang term with
But it does not have to happen in the same NIF call. Read-only binaries
do not have to be released.
enif_make_new_binary can be used as a shortcut to allocate and return a binary in the same NIF call.
Binaries are sequences of whole bytes. Bitstrings with an arbitrary bit length have no support yet.
The use of resource objects is a safe way to return pointers to
native data structures from a NIF. A resource object is
just a block of memory allocated with
A handle ("safe pointer") to this memory block can then be returned to Erlang by the use of
The term returned by
is totally opaque in nature. It can be stored and passed between processes
on the same node, but the only real end usage is to pass it back as an argument to a NIF.
The NIF can then call enif_get_resource
and get back a pointer to the memory block that is guaranteed to still be
valid. A resource object will not be deallocated until the last handle term
has been garbage collected by the VM and the resource has been
released with enif_release_resource
(not necessarily in that order).
All resource objects are created as instances of some resource type.
This makes resources from different modules to be distinguishable.
A resource type is created by calling
when a library is loaded. Objects of that resource type can then later be allocated
enif_get_resource verifies that the resource is of the expected type.
A resource type can have a user supplied destructor function that is
automatically called when resources of that type are released (by either
the garbage collector or
enif_release_resource). Resource types
are uniquely identified by a supplied name string and the name of the
implementing module.
Here is a template example of how to create and return a resource object.
ERL_NIF_TERM term; MyStruct* obj = enif_alloc_resource(my_resource_type, sizeof(MyStruct)); /* initialize struct ... */ term = enif_make_resource(env, obj); if (keep_a_reference_of_our_own) { /* store 'obj' in static variable, private data or other resource object */ } else { enif_release_resource(obj); /* resource now only owned by "Erlang" */ } return term;
Note that once
enif_make_resource creates the term to
return to Erlang, the code can choose to either keep its own
native pointer to the allocated struct and release it later, or
release it immediately and rely solely on the garbage collector
to eventually deallocate the resource object when it collects
the term.
Another usage of resource objects is to create binary terms with
user defined memory management.
will create a binary term that is connected to a resource object. The
destructor of the resource will be called when the binary is garbage
collected, at which time the binary data can be released. An example of
this can be a binary term consisting of data from a
mmap'ed file.
The destructor can then do
munmap to release the memory
Resource types support upgrade in runtime by allowing a loaded NIF library to takeover an already existing resource type and thereby "inherit" all existing objects of that type. The destructor of the new library will thereafter be called for the inherited objects and the library with the old destructor function can be safely unloaded. Existing resource objects, of a module that is upgraded, must either be deleted or taken over by the new NIF library. The unloading of a library will be postponed as long as there exist resource objects with a destructor function in the library.
A NIF is thread-safe without any explicit synchronization as long as it acts as a pure function and only reads the supplied arguments. As soon as you write towards a shared state either through static variables or enif_priv_data you need to supply your own explicit synchronization. This includes terms in process independent environments that are shared between threads. Resource objects will also require synchronization if you treat them as mutable.
The library initialization callbacks
reload and
upgrade are all thread-safe even for shared state data.
Note that the dirty NIF functionality is experimental and that you have to enable support for dirty schedulers when building OTP in order to try the functionality out. Native functions must normally run quickly, as explained earlier in this document. They generally should execute for no more than a millisecond. But not all native functions can execute so quickly; for example, functions that encrypt large blocks of data or perform lengthy file system operations can often run for tens of seconds or more.
A NIF that cannot execute in a millisecond or less is called a "dirty NIF" since it performs work that the Erlang runtime cannot handle cleanly. Applications that make use of such functions must indicate to the runtime that the functions are dirty so they can be handled specially. To schedule a dirty NIF for execution, the application calls enif_schedule_dirty_nif, passing to it a pointer to the dirty NIF to be executed and indicating with a flag argument whether it expects the operation to be CPU-bound or I/O-bound.
All dirty NIFs must ultimately invoke the enif_schedule_dirty_nif_finalizer as their final action, passing to it the result they wish to return to the original caller. A finalizer function can either receive the result and return it directly, or it can return a different value instead. For convenience, the NIF API provides the enif_dirty_nif_finalizer function that applications can use as a finalizer; it simply returns its result argument.
Dirty NIF support is available only when the emulator is configured with dirty
schedulers enabled. This feature is currently disabled by default. To determine whether
the dirty NIF API is available, native code can check to see if the C preprocessor macro
ERL_NIF_DIRTY_SCHEDULER_SUPPORT is defined. Also, if the Erlang runtime was built
without threading support, dirty schedulers are disabled. To check at runtime for the presence
of dirty scheduler threads, code can call the
enif_have_dirty_schedulers() API function, which returns true if dirty
scheduler threads are present, false otherwise.
This is the magic macro to initialize a NIF library. It should be evaluated in global file scope.
MODULE is the name of the Erlang module as an
identifier without string quotations. It will be stringified by
the macro.
funcs is a static array of function descriptors for
all the implemented NIFs in this library.
upgrade and
are pointers to functions. One of
reload or
upgrade will be called to initialize the library.
unload is called to release the library. They are all
described individually below.
If compiling a nif for static inclusion via --enable-static-nifs you have to define STATIC_ERLANG_NIF before the ERL_NIF_INIT declaration.
load is called when the NIF library is loaded
and there is no previously loaded library for this module.
*priv_data can be set to point to some private data
that the library needs in order to keep a state between NIF
enif_priv_data will return this pointer.
*priv_data will be initialized to NULL when
load is
load_info is the second argument to erlang:load_nif/2.
The library will fail to load if
load returns
anything other than 0.
load can be NULL in case no
initialization is needed.
upgrade is called when the NIF library is loaded
and there is old code of this module with a loaded NIF library.
Works the same as
load. The only difference is that
*old_priv_data already contains the value set by the
last call to
load or
reload for the old module
*priv_data will be initialized to NULL when
is called. It is allowed to write to both *priv_data and *old_priv_data.
The library will fail to load if
upgrade returns
anything other than 0 or if
upgrade is NULL.
unload is called when the module code that
the NIF library belongs to is purged as old. New code
of the same module may or may not exist. Note that
unload is not
called for a replaced library as a consequence of
The reload mechanism is deprecated. It was only intended
as a development feature. Do not use it as an upgrade method for
live production systems. It might be removed in future releases. Be sure
to pass
reload as
NULL to ERL_NIF_INIT
to disable it when not used.
reload is called when the NIF library is loaded
and there is already a previously loaded library for this
module code.
Works the same as
load. The only difference is that
*priv_data already contains the value set by the
previous call to
load or
The library will fail to load if
reload returns
anything other than 0 or if
reload is NULL.
Variables of type
ERL_NIF_TERM can refer to any Erlang term.
This is an opaque type and values of it can only by used either as
arguments to API functions or as return values from NIFs. All
ERL_NIF_TERM's belong to an environment
(ErlNifEnv). A term can not be
destructed individually, it is valid until its environment is destructed.
ErlNifEnv represents an environment that can host Erlang terms.
All terms in an environment are valid as long as the environment is valid.
ErlNifEnv is an opaque type and pointers to it can only be passed
on to API functions. There are two types of environments; process
bound and process independent.
A process bound environment is passed as the first argument to all NIFs. All function arguments passed to a NIF will belong to that environment. The return value from a NIF must also be a term belonging to the same environment. In addition a process bound environment contains transient information about the calling Erlang process. The environment is only valid in the thread where it was supplied as argument until the NIF returns. It is thus useless and dangerous to store pointers to process bound environments between NIF calls.
A process independent environment is created by calling
enif_alloc_env. It can be
used to store terms between NIF calls and to send terms with
enif_send. A process
independent environment with all its terms is valid until you explicitly
invalidates it with enif_free_env
All elements of a list/tuple must belong to the same environment as the list/tuple itself. Terms can be copied between environments with enif_make_copy.
typedef struct { const char* name; unsigned arity; ERL_NIF_TERM (*fptr)(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]); } ErlNifFunc;
Describes a NIF by its name, arity and implementation.
fptr is a pointer to the function that implements the
NIF. The argument
argv of a NIF will contain the
function arguments passed to the NIF and
argc is the
length of the array, i.e. the function arity.
will thus denote the Nth argument to the NIF. Note that the
argc argument allows for the same C function to
implement several Erlang functions with different arity (but
same name probably).
typedef struct { unsigned size; unsigned char* data; } ErlNifBinary;
ErlNifBinary contains transient information about an
inspected binary term.
data is a pointer to a buffer
size bytes with the raw content of the binary.
Note that
ErlNifBinary is a semi-opaque type and you are
only allowed to read fields
size and
ErlNifPid is a process identifier (pid). In contrast to
pid terms (instances of
ErlNifPid's are self
contained and not bound to any
is an opaque type.
Each instance of
ErlNifResourceType represent a class of
memory managed resource objects that can be garbage collected.
Each resource type has a unique name and a destructor function that
is called when objects of its type are released.
typedef void ErlNifResourceDtor(ErlNifEnv* env, void* obj);
The function prototype of a resource destructor function. A destructor function is not allowed to call any term-making functions.
typedef enum { ERL_NIF_LATIN1 }ErlNifCharEncoding;
The character encoding used in strings and atoms. The only
supported encoding is currently
ERL_NIF_LATIN1 for
iso-latin-1 (8-bit ascii).
Used by enif_system_info to return information about the runtime system. Contains currently the exact same content as ErlDrvSysInfo.
A native signed 64-bit integer type.
A native unsigned 64-bit integer type.
void * enif_alloc(size_t size)
Allocate memory of
size bytes. Return NULL if allocation failed.
int enif_alloc_binary(size_t size, ErlNifBinary* bin)
Allocate a new binary of size
bytes. Initialize the structure pointed to by
bin to
refer to the allocated binary. The binary must either be released by
or ownership transferred to an Erlang term with
An allocated (and owned)
ErlNifBinary can be kept between NIF
Return true on success or false if allocation failed.
ErlNifEnv * enif_alloc_env()
Allocate a new process independent environment. The environment can be used to hold terms that is not bound to any process. Such terms can later be copied to a process environment with enif_make_copy or be sent to a process as a message with enif_send.
Return pointer to the new environment.
void * enif_alloc_resource(ErlNifResourceType* type, unsigned size)
Allocate a memory managed resource object of type
type and size
size bytes.
void enif_clear_env(ErlNifEnv* env)
Free all terms in an environment and clear it for reuse. The environment must have been allocated with enif_alloc_env.
int enif_compare(ERL_NIF_TERM lhs, ERL_NIF_TERM rhs)
Return an integer less than, equal to, or greater than
zero if
lhs is found, respectively, to be less than,
equal, or greater than
rhs. Corresponds to the Erlang
>= and
> (but not
=:= or
void enif_cond_broadcast(ErlNifCond *cnd)
Same as erl_drv_cond_broadcast.
ErlNifCond * enif_cond_create(char *name)
Same as erl_drv_cond_create.
void enif_cond_destroy(ErlNifCond *cnd)
Same as erl_drv_cond_destroy.
void enif_cond_signal(ErlNifCond *cnd)
Same as erl_drv_cond_signal.
void enif_cond_wait(ErlNifCond *cnd, ErlNifMutex *mtx)
Same as erl_drv_cond_wait.
int enif_consume_timeslice(ErlNifEnv *env, int percent)
Give the runtime system a hint about how much CPU time the current NIF call has consumed
since last hint, or since the start of the NIF if no previous hint has been given.
The time is given as a
percent of the timeslice that a process is allowed to execute Erlang
code until it may be suspended to give time for other runnable processes.
The scheduling timeslice is not an exact entity, but can usually be
approximated to about 1 millisecond.
Note that it is up to the runtime system to determine if and how to use this information.
Implementations on some platforms may use other means in order to determine consumed
CPU time. Lengthy NIFs should regardless of this frequently call
in order to determine if it is allowed to continue execution or not.
Returns 1 if the timeslice is exhausted, or 0 otherwise. If 1 is returned the NIF should return as soon as possible in order for the process to yield.
percent must be an integer between 1 and 100. This function
must only be called from a NIF-calling thread and argument
env must be
the environment of the calling process.
This function is provided to better support co-operative scheduling, improve system responsiveness, and make it easier to prevent misbehaviors of the VM due to a NIF monopolizing a scheduler thread. It can be used to divide length work into a number of repeated NIF-calls without the need to create threads. See also the warning text at the beginning of this document.
ERL_NIF_TERM enif_dirty_nif_finalizer(ErlNifEnv* env, ERL_NIF_TERM result)
A convenience function that a dirty NIF can use as a finalizer that simply
return its
result argument as its return value. This function is provided
for dirty NIFs with results that should be returned directly to the original caller.
This function is available only when the emulator is configured with dirty
schedulers enabled. This feature is currently disabled by default. To determine whether
the dirty NIF API is available, native code can check to see if the C preprocessor macro
ERL_NIF_DIRTY_SCHEDULER_SUPPORT is defined.
int enif_equal_tids(ErlNifTid tid1, ErlNifTid tid2)
Same as erl_drv_equal_tids.
void enif_free(void* ptr)
Free memory allocated by
void enif_free_env(ErlNifEnv* env)
Free an environment allocated with enif_alloc_env. All terms created in the environment will be freed as well.
int enif_get_atom(ErlNifEnv* env, ERL_NIF_TERM term, char* buf, unsigned size, ErlNifCharEncoding encode)
Write a null-terminated string, in the buffer pointed to by
buf of size
size, consisting of the string
representation of the atom
term with encoding
encode. Return
the number of bytes written (including terminating null character) or 0 if
term is not an atom with maximum length of
int enif_get_atom_length(ErlNifEnv* env, ERL_NIF_TERM term, unsigned* len, ErlNifCharEncoding encode)
*len to the length (number of bytes excluding
terminating null character) of the atom
term with encoding
encode. Return true on success or false if
term is not an
int enif_get_double(ErlNifEnv* env, ERL_NIF_TERM term, double* dp)
*dp to the floating point value of
term. Return true on success or false if
term is not a float.
int enif_get_int(ErlNifEnv* env, ERL_NIF_TERM term, int* ip)
*ip to the integer value of
term. Return true on success or false if
term is not an
integer or is outside the bounds of type
int enif_get_int64(ErlNifEnv* env, ERL_NIF_TERM term, ErlNifSInt64* ip)
*ip to the integer value of
term. Return true on success or false if
term is not an
integer or is outside the bounds of a signed 64-bit integer.
int enif_get_local_pid(ErlNifEnv* env, ERL_NIF_TERM term, ErlNifPid* pid)
term is the pid of a node local process, initialize the
pid variable
*pid from it and return true. Otherwise return false.
No check if the process is alive is done.
int enif_get_list_cell(ErlNifEnv* env, ERL_NIF_TERM list, ERL_NIF_TERM* head, ERL_NIF_TERM* tail)
*head and
*tail from
list and return true, or return false if
list is not a
non-empty list.
int enif_get_list_length(ErlNifEnv* env, ERL_NIF_TERM term, unsigned* len)
*len to the length of list
term and return true,
or return false if
term is not a list.
int enif_get_long(ErlNifEnv* env, ERL_NIF_TERM term, long int* ip)
*ip to the long integer value of
term and
return true, or return false if
term is not an integer or is
outside the bounds of type
long int.
int enif_get_resource(ErlNifEnv* env, ERL_NIF_TERM term, ErlNifResourceType* type, void** objp)
*objp to point to the resource object referred to by
Return true on success or false if
term is not a handle to a resource object
of type
int enif_get_string(ErlNifEnv* env, ERL_NIF_TERM list, char* buf, unsigned size, ErlNifCharEncoding encode)
Write a null-terminated string, in the buffer pointed to by
buf with size
size, consisting of the characters
in the string
list. The characters are written using encoding
Return the number of bytes written (including terminating null
character), or
-size if the string was truncated due to
buffer space, or 0 if
list is not a string that can be
encoded with
encode or if
size was less than 1.
The written string is always null-terminated unless buffer
size is less than 1.
int enif_get_tuple(ErlNifEnv* env, ERL_NIF_TERM term, int* arity, const ERL_NIF_TERM** array)
term is a tuple, set
*array to point
to an array containing the elements of the tuple and set
*arity to the number of elements. Note that the array
is read-only and
(*array)[N-1] will be the Nth element of
the tuple.
*array is undefined if the arity of the tuple
is zero.
Return true on success or false if
term is not a
int enif_get_uint(ErlNifEnv* env, ERL_NIF_TERM term, unsigned int* ip)
*ip to the unsigned integer value of
term and
return true, or return false if
term is not an unsigned integer or
is outside the bounds of type
unsigned int.
int enif_get_uint64(ErlNifEnv* env, ERL_NIF_TERM term, ErlNifUInt64* ip)
*ip to the unsigned integer value of
term and
return true, or return false if
term is not an unsigned integer or
is outside the bounds of an unsigned 64-bit integer.
int enif_get_ulong(ErlNifEnv* env, ERL_NIF_TERM term, unsigned long* ip)
*ip to the unsigned long integer value of
and return true, or return false if
term is not an unsigned integer or is
outside the bounds of type
unsigned long.
int enif_have_dirty_schedulers()
Check at runtime for the presence of dirty scheduler threads. If the emulator is
built with threading support, dirty scheduler threads are available and
enif_have_dirty_schedulers() returns true. If the emulator was built without
threading support,
enif_have_dirty_schedulers() returns false.
If dirty scheduler threads are not available in the emulator, calls to
enif_schedule_dirty_nif and
enif_schedule_dirty_nif_finalizer result in
the NIF and finalizer functions being called directly within the calling thread.
This function is available only when the emulator is configured with dirty
schedulers enabled. This feature is currently disabled by default. To determine whether
the dirty NIF API is available, native code can check to see if the C preprocessor macro
ERL_NIF_DIRTY_SCHEDULER_SUPPORT is defined.
int enif_inspect_binary(ErlNifEnv* env, ERL_NIF_TERM bin_term, ErlNifBinary* bin)
Initialize the structure pointed to by
bin with
information about the binary term
bin_term. Return true on success or false if
bin_term is not a binary.
int enif_inspect_iolist_as_binary(ErlNifEnv* env, ERL_NIF_TERM term, ErlNifBinary* bin)
Initialize the structure pointed to by
bin with one
continuous buffer with the same byte content as
iolist. As with
inspect_binary, the data pointed to by
bin is transient and does
not need to be released. Return true on success or false if
iolist is not an
int enif_is_atom(ErlNifEnv* env, ERL_NIF_TERM term)
Return true if
term is an atom.
int enif_is_binary(ErlNifEnv* env, ERL_NIF_TERM term)
Return true if
term is a binary
int enif_is_empty_list(ErlNifEnv* env, ERL_NIF_TERM term)
Return true if
term is an empty list.
int enif_is_exception(ErlNifEnv* env, ERL_NIF_TERM term)
Return true if
term is an exception.
int enif_is_number(ErlNifEnv* env, ERL_NIF_TERM term)
Return true if
term is a number.
int enif_is_fun(ErlNifEnv* env, ERL_NIF_TERM term)
Return true if
term is a fun.
int enif_is_identical(ERL_NIF_TERM lhs, ERL_NIF_TERM rhs)
Return true if the two terms are identical. Corresponds to the
Erlang operators
=:= and
int enif_is_on_dirty_scheduler(ErlNifEnv* env)
Check to see if the current NIF is executing on a dirty scheduler thread. If the
emulator is built with threading support, calling
from within a dirty NIF returns true. It returns false when the calling NIF is a regular
NIF or a NIF finalizer, both of which run on normal scheduler threads, or when the emulator
is built without threading support.
This function is available only when the emulator is configured with dirty
schedulers enabled. This feature is currently disabled by default. To determine whether
the dirty NIF API is available, native code can check to see if the C preprocessor macro
ERL_NIF_DIRTY_SCHEDULER_SUPPORT is defined.
int enif_is_pid(ErlNifEnv* env, ERL_NIF_TERM term)
Return true if
term is a pid.
int enif_is_port(ErlNifEnv* env, ERL_NIF_TERM term)
Return true if
term is a port.
int enif_is_ref(ErlNifEnv* env, ERL_NIF_TERM term)
Return true if
term is a reference.
int enif_is_tuple(ErlNifEnv* env, ERL_NIF_TERM term)
Return true if
term is a tuple.
int enif_is_list(ErlNifEnv* env, ERL_NIF_TERM term)
Return true if
term is a list.
int enif_keep_resource(void* obj)
Add a reference to resource object
obj obtained from
Each call to
enif_keep_resource for an object must be balanced by
a call to enif_release_resource
before the object will be destructed.
ERL_NIF_TERM enif_make_atom(ErlNifEnv* env, const char* name)
Create an atom term from the null-terminated C-string
with iso-latin-1 encoding.
ERL_NIF_TERM enif_make_atom_len(ErlNifEnv* env, const char* name, size_t len)
Create an atom term from the string
name with length
Null-characters are treated as any other characters.
ERL_NIF_TERM enif_make_badarg(ErlNifEnv* env)
Make a badarg exception to be returned from a NIF, and set
an associated exception reason in
env. If
enif_make_badarg is called, the term it returns must
be returned from the function that called it. No other return value
is allowed. Also, the term returned from
enif_make_badarg may
be passed only to
enif_is_exception and
not to any other NIF API function.
ERL_NIF_TERM enif_make_binary(ErlNifEnv* env, ErlNifBinary* bin)
Make a binary term from
bin. Any ownership of
the binary data will be transferred to the created term and
bin should be considered read-only for the rest of the NIF
call and then as released.
ERL_NIF_TERM enif_make_copy(ErlNifEnv* dst_env, ERL_NIF_TERM src_term)
Make a copy of term
src_term. The copy will be created in
dst_env. The source term may be located in any
ERL_NIF_TERM enif_make_double(ErlNifEnv* env, double d)
Create a floating-point term from a
int enif_make_existing_atom(ErlNifEnv* env, const char* name, ERL_NIF_TERM* atom, ErlNifCharEncoding encode)
Try to create the term of an already existing atom from
the null-terminated C-string
name with encoding
encode. If the atom
already exists store the term in
*atom and return true, otherwise
return false.
int enif_make_existing_atom_len(ErlNifEnv* env, const char* name, size_t len, ERL_NIF_TERM* atom, ErlNifCharEncoding encoding)
Try to create the term of an already existing atom from the
name with length
len and encoding
encode. Null-characters
are treated as any other characters. If the atom already exists store the term
*atom and return true, otherwise return false.
ERL_NIF_TERM enif_make_int(ErlNifEnv* env, int i)
Create an integer term.
ERL_NIF_TERM enif_make_int64(ErlNifEnv* env, ErlNifSInt64 i)
Create an integer term from a signed 64-bit integer.
ERL_NIF_TERM enif_make_list(ErlNifEnv* env, unsigned cnt, ...)
Create an ordinary list term of length
cnt. Expects
cnt number of arguments (after
cnt) of type ERL_NIF_TERM as the
elements of the list. An empty list is returned if
cnt is 0.
ERL_NIF_TERM enif_make_list1(ErlNifEnv* env, ERL_NIF_TERM e1)
ERL_NIF_TERM enif_make_list2(ErlNifEnv* env, ERL_NIF_TERM e1, ERL_NIF_TERM e2)
ERL_NIF_TERM enif_make_list3(ErlNifEnv* env, ERL_NIF_TERM e1, ERL_NIF_TERM e2, ERL_NIF_TERM e3)
ERL_NIF_TERM enif_make_list4(ErlNifEnv* env, ERL_NIF_TERM e1, ..., ERL_NIF_TERM e4)
ERL_NIF_TERM enif_make_list5(ErlNifEnv* env, ERL_NIF_TERM e1, ..., ERL_NIF_TERM e5)
ERL_NIF_TERM enif_make_list6(ErlNifEnv* env, ERL_NIF_TERM e1, ..., ERL_NIF_TERM e6)
ERL_NIF_TERM enif_make_list7(ErlNifEnv* env, ERL_NIF_TERM e1, ..., ERL_NIF_TERM e7)
ERL_NIF_TERM enif_make_list8(ErlNifEnv* env, ERL_NIF_TERM e1, ..., ERL_NIF_TERM e8)
ERL_NIF_TERM enif_make_list9(ErlNifEnv* env, ERL_NIF_TERM e1, ..., ERL_NIF_TERM e9)
Create an ordinary list term with length indicated by the
function name. Prefer these functions (macros) over the variadic
enif_make_list to get a compile time error if the number of
arguments does not match.
ERL_NIF_TERM enif_make_list_cell(ErlNifEnv* env, ERL_NIF_TERM head, ERL_NIF_TERM tail)
Create a list cell
[head | tail].
ERL_NIF_TERM enif_make_list_from_array(ErlNifEnv* env, const ERL_NIF_TERM arr[], unsigned cnt)
Create an ordinary list containing the elements of array
of length
cnt. An empty list is returned if
cnt is 0.
int enif_make_reverse_list(ErlNifEnv* env, ERL_NIF_TERM term, ERL_NIF_TERM *list)
*list to the reverse list of the list
term and return true,
or return false if
term is not a list. This function should only be used on
short lists as a copy will be created of the list which will not be released until after the
nif returns.
ERL_NIF_TERM enif_make_long(ErlNifEnv* env, long int i)
Create an integer term from a
long int.
unsigned char * enif_make_new_binary(ErlNifEnv* env, size_t size, ERL_NIF_TERM* termp)
Allocate a binary of size
size bytes and create an owning
term. The binary data is mutable until the calling NIF returns. This is a
quick way to create a new binary without having to use
ErlNifBinary. The drawbacks are
that the binary can not be kept between NIF calls and it can not be
Return a pointer to the raw binary data and set
*termp to the binary term.
ERL_NIF_TERM enif_make_pid(ErlNifEnv* env, const ErlNifPid* pid)
Make a pid term from
ERL_NIF_TERM enif_make_ref(ErlNifEnv* env)
Create a reference like erlang:make_ref/0.
ERL_NIF_TERM enif_make_resource(ErlNifEnv* env, void* obj)
Create an opaque handle to a memory managed resource object
obtained by enif_alloc_resource.
No ownership transfer is done, as the resource object still needs to be released by
but note that the call to
enif_release_resource can occur
immediately after obtaining the term from
in which case the resource object will be deallocated when the
term is garbage collected. See the
example of creating and
returning a resource object for more details.
Note that the only defined behaviour of using a resource term in
an Erlang program is to store it and send it between processes on the
same node. Other operations such as matching or
will have unpredictable (but harmless) results.
ERL_NIF_TERM enif_make_resource_binary(ErlNifEnv* env, void* obj, const void* data, size_t size)
Create a binary term that is memory managed by a resource object
obj obtained by enif_alloc_resource.
The returned binary term will consist of
size bytes pointed to
data. This raw binary data must be kept readable and unchanged
until the destructor of the resource is called. The binary data may be
stored external to the resource object in which case it is the responsibility
of the destructor to release the data.
Several binary terms may be managed by the same resource object. The destructor will not be called until the last binary is garbage collected. This can be useful as a way to return different parts of a larger binary buffer.
As with enif_make_resource, no ownership transfer is done. The resource still needs to be released with enif_release_resource.
ERL_NIF_TERM enif_make_string(ErlNifEnv* env, const char* string, ErlNifCharEncoding encoding)
Create a list containing the characters of the
null-terminated string
string with encoding encoding.
ERL_NIF_TERM enif_make_string_len(ErlNifEnv* env, const char* string, size_t len, ErlNifCharEncoding encoding)
Create a list containing the characters of the string
string with
len and encoding encoding.
Null-characters are treated as any other characters.
ERL_NIF_TERM enif_make_sub_binary(ErlNifEnv* env, ERL_NIF_TERM bin_term, size_t pos, size_t size)
Make a subbinary of binary
bin_term, starting at
zero-based position
pos with a length of
size bytes.
bin_term must be a binary or bitstring and
pos+size must be less or equal to the number of whole
bytes in
ERL_NIF_TERM enif_make_tuple(ErlNifEnv* env, unsigned cnt, ...)
Create a tuple term of arity
cnt. Expects
cnt number of arguments (after
cnt) of type ERL_NIF_TERM as the
elements of the tuple.
ERL_NIF_TERM enif_make_tuple1(ErlNifEnv* env, ERL_NIF_TERM e1)
ERL_NIF_TERM enif_make_tuple2(ErlNifEnv* env, ERL_NIF_TERM e1, ERL_NIF_TERM e2)
ERL_NIF_TERM enif_make_tuple3(ErlNifEnv* env, ERL_NIF_TERM e1, ERL_NIF_TERM e2, ERL_NIF_TERM e3)
ERL_NIF_TERM enif_make_tuple4(ErlNifEnv* env, ERL_NIF_TERM e1, ..., ERL_NIF_TERM e4)
ERL_NIF_TERM enif_make_tuple5(ErlNifEnv* env, ERL_NIF_TERM e1, ..., ERL_NIF_TERM e5)
ERL_NIF_TERM enif_make_tuple6(ErlNifEnv* env, ERL_NIF_TERM e1, ..., ERL_NIF_TERM e6)
ERL_NIF_TERM enif_make_tuple7(ErlNifEnv* env, ERL_NIF_TERM e1, ..., ERL_NIF_TERM e7)
ERL_NIF_TERM enif_make_tuple8(ErlNifEnv* env, ERL_NIF_TERM e1, ..., ERL_NIF_TERM e8)
ERL_NIF_TERM enif_make_tuple9(ErlNifEnv* env, ERL_NIF_TERM e1, ..., ERL_NIF_TERM e9)
Create a tuple term with length indicated by the
function name. Prefer these functions (macros) over the variadic
enif_make_tuple to get a compile time error if the number of
arguments does not match.
ERL_NIF_TERM enif_make_tuple_from_array(ErlNifEnv* env, const ERL_NIF_TERM arr[], unsigned cnt)
Create a tuple containing the elements of array
of length
ERL_NIF_TERM enif_make_uint(ErlNifEnv* env, unsigned int i)
Create an integer term from an
unsigned int.
ERL_NIF_TERM enif_make_uint64(ErlNifEnv* env, ErlNifUInt64 i)
Create an integer term from an unsigned 64-bit integer.
ERL_NIF_TERM enif_make_ulong(ErlNifEnv* env, unsigned long i)
Create an integer term from an
unsigned long int.
ErlNifMutex * enif_mutex_create(char *name)
Same as erl_drv_mutex_create.
void enif_mutex_destroy(ErlNifMutex *mtx)
Same as erl_drv_mutex_destroy.
void enif_mutex_lock(ErlNifMutex *mtx)
Same as erl_drv_mutex_lock.
int enif_mutex_trylock(ErlNifMutex *mtx)
Same as erl_drv_mutex_trylock.
void enif_mutex_unlock(ErlNifMutex *mtx)
Same as erl_drv_mutex_unlock.
ErlNifResourceType * enif_open_resource_type(ErlNifEnv* env, const char* module_str, const char* name, ErlNifResourceDtor* dtor, ErlNifResourceFlags flags, ErlNifResourceFlags* tried)
Create or takeover a resource type identified by the string
name and give it the destructor function pointed to by dtor.
flags can have the following values:
dtor will be called both for existing instances
as well as new instances not yet created by the calling NIF library.
The two flag values can be combined with bitwise-or. The name of the
resource type is local to the calling module. Argument
is not (yet) used and must be NULL. The
dtor may be
in case no destructor is needed.
On success, return a pointer to the resource type and
will be set to either
ERL_NIF_RT_CREATE or
ERL_NIF_RT_TAKEOVER to indicate what was actually done.
On failure, return
NULL and set
*tried to
It is allowed to set
tried to
Note that
enif_open_resource_type is only allowed to be called in the three callbacks
load, reload
and upgrade.
void * enif_priv_data(ErlNifEnv* env)
Return the pointer to the private data that was set by
reload or
Was previously named
int enif_realloc_binary(ErlNifBinary* bin, size_t size)
Change the size of a binary
bin. The source binary
may be read-only, in which case it will be left untouched and
a mutable copy is allocated and assigned to
*bin. Return true on success,
false if memory allocation failed.
void enif_release_binary(ErlNifBinary* bin)
Release a binary obtained from
void enif_release_resource(void* obj)
Remove a reference to resource object
objobtained from
The resource object will be destructed when the last reference is removed.
Each call to
enif_release_resource must correspond to a previous
call to
enif_alloc_resource or
References made by enif_make_resource
can only be removed by the garbage collector.
ErlNifRWLock * enif_rwlock_create(char *name)
Same as erl_drv_rwlock_create.
void enif_rwlock_destroy(ErlNifRWLock *rwlck)
Same as erl_drv_rwlock_destroy.
void enif_rwlock_rlock(ErlNifRWLock *rwlck)
Same as erl_drv_rwlock_rlock.
void enif_rwlock_runlock(ErlNifRWLock *rwlck)
Same as erl_drv_rwlock_runlock.
void enif_rwlock_rwlock(ErlNifRWLock *rwlck)
Same as erl_drv_rwlock_rwlock.
void enif_rwlock_rwunlock(ErlNifRWLock *rwlck)
Same as erl_drv_rwlock_rwunlock.
int enif_rwlock_tryrlock(ErlNifRWLock *rwlck)
Same as erl_drv_rwlock_tryrlock.
int enif_rwlock_tryrwlock(ErlNifRWLock *rwlck)
Same as erl_drv_rwlock_tryrwlock.
ERL_NIF_TERM enif_schedule_dirty_nif(ErlNifEnv* env, int flags, ERL_NIF_TERM (*fp)(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]), int argc, const ERL_NIF_TERM argv[])
Schedule dirty NIF
fp to execute a long-running operation. The
argument must be set to either
ERL_NIF_DIRTY_JOB_CPU_BOUND if the job is expected to
be primarily CPU-bound, or
ERL_NIF_DIRTY_JOB_IO_BOUND for jobs that will be
I/O-bound. The
argc and
argv arguments can either be the originals passed
into the calling NIF, or they can be values created by the calling NIF. The calling
NIF must use the return value of
enif_schedule_dirty_nif as its own return value.
Be aware that
enif_schedule_dirty_nif, as its name implies, only schedules the
dirty NIF for future execution. The calling NIF does not block waiting for the dirty NIF to
execute and return, which means that the calling NIF can't expect to receive the dirty NIF
return value and use it for further operations.
A dirty NIF may not invoke the enif_make_badarg to raise an exception. If it wishes to return an exception, the dirty NIF should pass a regular result indicating the exception details to its finalizer, and allow the finalizer to raise the exception on its behalf.
This function is available only when the emulator is configured with dirty schedulers
enabled. This feature is currently disabled by default. To determine whether the dirty NIF API
is available, native code can check to see if the C preprocessor macro
ERL_NIF_DIRTY_SCHEDULER_SUPPORT is defined.
ERL_NIF_TERM enif_schedule_dirty_nif_finalizer(ErlNifEnv* env, ERL_NIF_TERM result, ERL_NIF_TERM (*fp)(ErlNifEnv* env, ERL_NIF_TERM result))
When a dirty NIF finishes executing, it must schedule a finalizer function to return
its result to the original NIF caller. The dirty NIF passes
result as the value it
wants the finalizer to use as the return value. The
fp argument is a pointer to the
finalizer function. The NIF API provides the
enif_dirty_nif_finalizer function that can be used as a finalizer that simply
returns its
result argument. You are also free to write your own custom finalizer
that uses
result to derive a different return value, or ignores
entirely and returns a completely different value.
Without exception, all dirty NIFs must invoke
to complete their execution.
This function is available only when the emulator is configured with dirty
schedulers enabled. This feature is currently disabled by default. To determine whether
the dirty NIF API is available, native code can check to see if the C preprocessor macro
ERL_NIF_DIRTY_SCHEDULER_SUPPORT is defined.
ErlNifPid * enif_self(ErlNifEnv* caller_env, ErlNifPid* pid)
Initialize the pid variable
*pid to represent the
calling process. Return
int enif_send(ErlNifEnv* env, ErlNifPid* to_pid, ErlNifEnv* msg_env, ERL_NIF_TERM msg)
Send a message to a process.
Return true on success, or false if
*to_pid does not refer to an alive local process.
The message environment
msg_env with all its terms (including
msg) will be invalidated by a successful call to
enif_send. The environment
should either be freed with enif_free_env
of cleared for reuse with enif_clear_env.
This function is only thread-safe when the emulator with SMP support is used. It can only be used in a non-SMP emulator from a NIF-calling thread.
unsigned enif_sizeof_resource(void* obj)
Get the byte size of a resource object
obj obtained by
void enif_system_info(ErlNifSysInfo *sys_info_ptr, size_t size)
Same as driver_system_info.
int enif_thread_create(char *name,ErlNifTid *tid,void * (*func)(void *),void *args,ErlNifThreadOpts *opts)
Same as erl_drv_thread_create.
void enif_thread_exit(void *resp)
Same as erl_drv_thread_exit.
int enif_thread_join(ErlNifTid, void **respp)
Same as erl_drv_thread_join .
ErlNifThreadOpts * enif_thread_opts_create(char *name)
Same as erl_drv_thread_opts_create.
void enif_thread_opts_destroy(ErlNifThreadOpts *opts)
Same as erl_drv_thread_opts_destroy.
ErlNifTid enif_thread_self(void)
Same as erl_drv_thread_self.
int enif_tsd_key_create(char *name, ErlNifTSDKey *key)
Same as erl_drv_tsd_key_create.
void enif_tsd_key_destroy(ErlNifTSDKey key)
Same as erl_drv_tsd_key_destroy.
void * enif_tsd_get(ErlNifTSDKey key)
Same as erl_drv_tsd_get.
void enif_tsd_set(ErlNifTSDKey key, void *data)
Same as erl_drv_tsd_set.