NuttX Operating System

User's Manual

by

Gregory Nutt

Last Updated: May 25, 2020

1.0 Introduction

This manual provides general usage information for the NuttX RTOS from the perspective of the firmware developer.

1.1 Document Overview

This user's manual is divided into three sections plus a index:

1.2 Intended Audience and Scope

The intended audience for this document are firmware developers who are implementing applications on NuttX. Specifically, this documented is limited to addressing only NuttX RTOS APIs that are available to the application developer. As such, this document does not focus on any technical details of the organization or implementation of NuttX. Those technical details are provided in the NuttX Porting Guide.

Information about configuring and building NuttX is also needed by the application developer. That information can also be found in the NuttX Porting Guide.

2.0 OS Interfaces

This section describes each C-callable interface to the NuttX Operating System. The description of each interface is presented in the following format:

Function Prototype: The C prototype of the interface function is provided.

Description: The operation performed by the interface function is discussed.

Input Parameters: All input parameters are listed along with brief descriptions of each input parameter.

Returned Value: All possible values returned by the interface function are listed. Values returned as side-effects (through pointer input parameters or through global variables) will be addressed in the description of the interface function.

Assumptions/Limitations: Any unusual assumptions made by the interface function or any non-obvious limitations to the use of the interface function will be indicated here.

POSIX Compatibility: Any significant differences between the NuttX interface and its corresponding POSIX interface will be noted here.

NOTE: In order to achieve an independent name space for the NuttX interface functions, differences in function names and types are to be expected and will not be identified as differences in these paragraphs.

2.1 Task Control Interfaces

Tasks. NuttX is a flat address OS. As such it does not support processes in the way that, say, Linux does. NuttX only supports simple threads running within the same address space. However, the programming model makes a distinction between tasks and pthreads:

File Descriptors and Streams. This applies, in particular, in the area of opened file descriptors and streams. When a task is started using the interfaces in this section, it will be created with at most three open files.

If CONFIG_DEV_CONSOLE is defined, the first three file descriptors (corresponding to stdin, stdout, stderr) will be duplicated for the new task. Since these file descriptors are duplicated, the child task can free close them or manipulate them in any way without effecting the parent task. File-related operations (open, close, etc.) within a task will have no effect on other tasks. Since the three file descriptors are duplicated, it is also possible to perform some level of redirection.

pthreads, on the other hand, will always share file descriptors with the parent thread. In this case, file operations will have effect only all pthreads the were started from the same parent thread.

Executing Programs within a File System. NuttX also provides internal interfaces for the execution of separately built programs that reside in a file system. These internal interfaces are, however, non-standard and are documented with the NuttX binary loader and NXFLAT.

Task Control Interfaces. The following task control interfaces are provided by NuttX:

Non-standard task control interfaces inspired by VxWorks interfaces:

Non-standard extensions to VxWorks-like interfaces to support POSIX Cancellation Points.

Standard interfaces

Standard vfork and exec[v|l] interfaces:

Standard posix_spawn interfaces:

Non-standard task control interfaces inspired by posix_spawn:

2.1.1 task_create

Function Prototype:

Description: This function creates and activates a new task with a specified priority and returns its system-assigned ID.

The entry address entry is the address of the "main" function of the task. This function will be called once the C environment has been set up. The specified function will be called with four arguments. Should the specified routine return, a call to exit() will automatically be made.

Note that an arbitrary number of arguments may be passed to the spawned functions.

The arguments are copied (via strdup) so that the life of the passed strings is not dependent on the life of the caller to task_create().

The newly created task does not inherit scheduler characteristics from the parent task: The new task is started at the default system priority and with the SCHED_FIFO scheduling policy. These characteristics may be modified after the new task has been started.

The newly created task does inherit the first three file descriptors (corresponding to stdin, stdout, and stderr) and redirection of standard I/O is supported.

Input Parameters:

Returned Value:

Assumptions/Limitations:

POSIX Compatibility: This is a NON-POSIX interface. VxWorks provides the following similar interface: 

   int taskSpawn(char *name, int priority, int options, int stackSize, FUNCPTR entryPt,
                 int arg1, int arg2, int arg3, int arg4, int arg5,
                 int arg6, int arg7, int arg8, int arg9, int arg10);

The NuttX task_create() differs from VxWorks' taskSpawn() in the following ways:

2.1.2 task_delete

Function Prototype:

Description: This function causes a specified task to cease to exist. Its stack and TCB will be deallocated. This function is the companion to task_create(). This is the version of the function exposed to the user; it is simply a wrapper around the internal, nxtask_terminate() function.

The logic in this function only deletes non-running tasks. If the pid parameter refers to the currently running task, then processing is redirected to exit(). This can only happen if a task calls task_delete() in order to delete itself.

This function obeys the semantics of pthread cancellation: task deletion is deferred if cancellation is disabled or if deferred cancellation is supported (with Cancellation Points enabled).

Input Parameters:

Returned Value:

Assumptions/Limitations:

task_delete() must be used with caution: If the task holds resources (for example, allocated memory or semaphores needed by other tasks), then task_delete() can strand those resources.

POSIX Compatibility: This is a NON-POSIX interface. VxWorks provides the following similar interface:

The NuttX task_delete() differs from VxWorks' taskDelete() in the following ways:

2.1.3 task_restart

Function Prototype:

Description: This function "restarts" a task. The task is first terminated and then reinitialized with same ID, priority, original entry point, stack size, and parameters it had when it was first started.

NOTES:

  1. The normal task exit clean up is not performed. For example, file descriptors are not closed; any files opened prior to the restart will remain opened after the task is restarted.
  2. Memory allocated by the task before it was restart is not freed. A task that is subject to being restart must be designed in such a way as to avoid memory leaks.
  3. Initialized data is not reset. All global or static data is left in the same state as when the task was terminated. This feature may be used by restart task to detect that it has been restarted, for example.

Input Parameters:

Returned Value:

Assumptions/Limitations:

POSIX Compatibility: This is a NON-POSIX interface. VxWorks provides the following similar interface: 

    STATUS taskRestart (int tid);

The NuttX task_restart() differs from VxWorks' taskRestart() in the following ways:

2.1.6 task_setcancelstate

Function Prototype: 

    #include <sched.h>
    int task_setcancelstate(int state, int *oldstate);

Description: The task_setcancelstate() function atomically sets both the calling task's cancellability state to the indicated state and returns the previous cancellability state at the location referenced by oldstate. Legal values for state are TASK_CANCEL_ENABLE and TASK_CANCEL_DISABLE.

Any pending thread cancellation may occur at the time that the cancellation state is set to TASK_CANCEL_ENABLE.

The cancellability state and type of any newly created tasks are TASK_CANCEL_ENABLE and TASK_CANCEL_DEFERRED respectively.

Input Parameters:

Returned Value:

Zero (OK) on success; ERROR is returned on any failure with the errno value set appropriately:

Assumptions/Limitations:

POSIX Compatibility: This is a non-standard interface. It extends the functionality of pthread_setcancelstate() to tasks and supports use of task_delete().

2.1.7 task_setcanceltype

Function Prototype: 

    #include <sched.h>
    int task_setcanceltype(int type, FAR int *oldtype);

Description: The task_setcanceltype() function atomically both sets the calling task's cancellability type to the indicated type and returns the previous cancellability type at the location referenced by oldtype. Legal values for type are TASK_CANCEL_DEFERRED and TASK_CANCEL_ASYNCHRONOUS.

The cancellability state and type of any newly created tasks are TASK_CANCEL_ENABLE and TASK_CANCEL_DEFERRED respectively.

Input Parameters:

Returned Value:

Zero (OK) on success; ERROR is returned on any failure with the errno value set appropriately:

POSIX Compatibility: This is a non-standard interface. It extends the functionality of pthread_setcanceltype() to tasks and supports use of task_delete().

2.1.8 task_testcancel

Function Prototype: 

    #include <sched.h>
    void task_testcancel(void);

Description:

The task_testcancel() function creates a Cancellation Point in the calling task. The task_testcancel() function has no effect if cancellability is disabled.

Input Parameters: None

Returned Value: None

POSIX Compatibility: This is a non-standard interface. It extends the functionality of pthread_testcancel() to tasks and supports use of task_delete().

2.1.9 exit

Function Prototype: 

    #include <sched.h>
    void exit(int code);

    #include <nuttx/unistd.h>
    void _exit(int code);

Description: This function causes the calling task to cease to exist -- its stack and TCB will be deallocated. exit differs from _exit in that it flushes streams, closes file descriptors and will execute any function registered with atexit() or on_exit().

Input Parameters:

Returned Value: None.

Assumptions/Limitations:

POSIX Compatibility: This is equivalent to the ANSI interface: 

    void exit(int code);
And the UNIX interface: 
    void _exit(int code);

The NuttX exit() differs from ANSI exit() in the following ways:

2.1.10 getpid

Function Prototype: 

    #include <unistd.h>
    pid_t getpid(void);

Description: This function returns the task ID of the calling task. The task ID will be invalid if called at the interrupt level.

Input Parameters: None.

Returned Value:

Assumptions/Limitations:

POSIX Compatibility: Compatible with the POSIX interface of the same name.

2.1.11 vfork

Function Prototype:

Description: The vfork() function has the same effect as fork(), except that the behavior is undefined if the process created by vfork() either modifies any data other than a variable of type pid_t used to store the return value from vfork(), or returns from the function in which vfork() was called, or calls any other function before successfully calling _exit() or one of the exec family of functions.

NOTE: vfork() is not an independent NuttX feature, but is implemented in architecture-specific logic (using only helper functions from the NuttX core logic). As a result, vfork() may not be available on all architectures.

Input Parameters: None.

Returned Value: Upon successful completion, vfork() returns 0 to the child process and returns the process ID of the child process to the parent process. Otherwise, -1 is returned to the parent, no child process is created, and errno is set to indicate the error.

Assumptions/Limitations:

POSIX Compatibility: Compatible with the BSD/Linux interface of the same name. POSIX marks this interface as Obsolete.

2.1.12 exec

Function Prototype:

Description: This non-standard, NuttX function is similar to execv() and posix_spawn() but differs in the following ways;

This non-standard interface is included as a official NuttX API only because it is needed in certain build modes: exec() is probably the only want to load programs in the PROTECTED mode. Other file execution APIs rely on a symbol table provided by the OS. In the PROTECTED build mode, the OS cannot provide any meaningful symbolic information for execution of code in the user-space blob so that is the exec() function is really needed in that build case

The interface is available in the FLAT build mode although it is not really necessary in that case. It is currently used by some example code under the apps/ that that generate their own symbol tables for linking test programs. So although it is not necessary, it can still be useful.

The interface would be completely useless and will not be supported in the KERNEL build mode where the contrary is true: An application process cannot provide any meaning symbolic information for use in linking a different process.

NOTE: This function is flawed and useless without CONFIG_SCHED_ONEXIT and CONFIG_SCHED_HAVE_PARENT because without those features there is then no mechanism to unload the module once it exits.

Input Parameters:

Returned Value: Zero (OK) is returned on success; On any failure, exec() will return -1 (ERROR) and will set the errno value appropriately.

Assumptions/Limitations:

POSIX Compatibility: This is a non-standard interface unique to NuttX. Motivation for inclusion of this non-standard interface in certain build modes is discussed above.

2.1.13 execv

Function Prototype:

Description: The standard exec family of functions will replace the current process image with a new process image. The new image will be constructed from a regular, executable file called the new process image file. There will be no return from a successful exec, because the calling process image is overlaid by the new process image.

Simplified execl() and execv() functions are provided by NuttX for compatibility. NuttX is a tiny embedded RTOS that does not support processes and hence the concept of overlaying a tasks process image with a new process image does not make any sense. In NuttX, these functions are wrapper functions that:

  1. Call the non-standard binfmt function exec(), and then
  2. exit(0).

Note the inefficiency when execv() or execl() is called in the normal, two-step process: (1) first call vfork() to create a new thread, then (2) call execv() or execl() to replace the new thread with a program from the file system. Since the new thread will be terminated by the execv() or execl() call, it really served no purpose other than to support POSIX compatibility.

The non-standard binfmt function exec() needs to have (1) a symbol table that provides the list of symbols exported by the base code, and (2) the number of symbols in that table. This information is currently provided to exec() from execv() or execl() via NuttX configuration settings:

As a result of the above, the current implementations of execl() and execv() suffer from some incompatibilities that may or may not be addressed in a future version of NuttX. Other than just being an inefficient use of MCU resource, the most serious of these is that the exec'ed task will not have the same task ID as the vfork'ed function. So the parent function cannot know the ID of the exec'ed task.

Input Parameters:

Returned Value: This function does not return on success. On failure, it will return -1 (ERROR) and will set the errno value appropriately.

Assumptions/Limitations:

POSIX Compatibility: Similar with the POSIX interface of the same name. There are, however, several compatibility issues as detailed in the description above.

2.1.14 execl

Function Prototype:

Description: execl() is functionally equivalent to execv(), differing only in the form of its input parameters. See the description of execv() for additional information.

Input Parameters:

Returned Value: This function does not return on success. On failure, it will return -1 (ERROR) and will set the errno value appropriately.

Assumptions/Limitations:

POSIX Compatibility: Similar with the POSIX interface of the same name. There are, however, several compatibility issues as detailed in the description of execv().

2.1.14 posix_spawn and posix_spawnp

Function Prototype:

Description: The posix_spawn() and posix_spawnp() functions will create a new, child task, constructed from a regular executable file.

Input Parameters:

Returned Value: posix_spawn() and posix_spawnp() will return zero on success. Otherwise, an error number will be returned as the function return value to indicate the error:

Assumptions/Limitations:

POSIX Compatibility: The value of the argv[0] received by the child task is assigned by NuttX. For the caller of posix_spawn(), the provided argv[0] will correspond to argv[1] received by the new task.

2.1.15 posix_spawn_file_actions_init

Function Prototype:

Description: The posix_spawn_file_actions_init() function initializes the object referenced by file_actions to an empty set of file actions for subsequent use in a call to posix_spawn() or posix_spawnp().

Input Parameters:

Returned Value: On success, this function returns 0; on failure it will return an error number from <errno.h>.

2.1.16 posix_spawn_file_actions_destroy

Function Prototype:

Description: The posix_spawn_file_actions_destroy() function destroys the object referenced by file_actions which was previously initialized by posix_spawn_file_actions_init(), returning any resources obtained at the time of initialization to the system for subsequent reuse. A posix_spawn_file_actions_t may be reinitialized after having been destroyed, but must not be reused after destruction, unless it has been reinitialized.

Input Parameters:

Returned Value: On success, this function returns 0; on failure it will return an error number from <errno.h>

2.1.17 posix_spawn_file_actions_addclose

Function Prototype:

Description: The posix_spawn_file_actions_addclose() function adds a close operation to the list of operations associated with the object referenced by file_actions, for subsequent use in a call to posix_spawn() or posix_spawnp(). The descriptor referred to by fd is closed as if close() had been called on it prior to the new child process starting execution.

Input Parameters:

Returned Value: On success, this function returns 0; on failure it will return an error number from <errno.h>

2.1.18 posix_spawn_file_actions_adddup2

Function Prototype:

Description: The posix_spawn_file_actions_adddup2() function adds a dup2 operation to the list of operations associated with the object referenced by file_actions, for subsequent use in a call to posix_spawn() or posix_spawnp(). The descriptor referred to by fd2 is created as if dup2() had been called on fd1 prior to the new child process starting execution.

Input Parameters:

Returned Value: On success, this function returns 0; on failure it will return an error number from <errno.h>

2.1.19 posix_spawn_file_actions_addopen

Function Prototype:

Description: The posix_spawn_file_actions_addopen() function adds an open operation to the list of operations associated with the object referenced by file_actions, for subsequent use in a call to posix_spawn() or posix_spawnp(). The descriptor referred to by fd is opened using the path, oflag, and mode arguments as if open() had been called on it prior to the new child process starting execution. The string path is copied by the posix_spawn_file_actions_addopen() function during this process, so storage need not be persistent in the caller.

Input Parameters:

Returned Value: On success, this function returns 0; on failure it will return an error number from <errno.h>

2.1.20 posix_spawnattr_init

Function Prototype:

Description: The posix_spawnattr_init() function initializes the object referenced by attr, to an empty set of spawn attributes for subsequent use in a call to posix_spawn() or posix_spawnp().

Then the spawn attributes are no longer needed, they should be destroyed by calling posix_spawnattr_destroyed(). In NuttX, however, posix_spawnattr_destroyed() is just stub:

For portability, the convention of calling posix_spawnattr_destroyed() when the attributes are not longer needed should still be followed.

Input Parameters:

Returned Value: On success, this function returns 0; on failure it will return an error number from <errno.h>

2.1.21 posix_spawnattr_getflags

Function Prototype:

Description: The posix_spawnattr_getflags() function will obtain the value of the spawn-flags attribute from the attributes object referenced by attr.

Input Parameters:

Returned Value: On success, this function returns 0; on failure it will return an error number from <errno.h>

2.1.22 posix_spawnattr_getschedparam

Function Prototype:

Description: The posix_spawnattr_getschedparam() function will obtain the value of the spawn-schedparam attribute from the attributes object referenced by attr.

Input Parameters:

Returned Value: On success, this function returns 0; on failure it will return an error number from <errno.h>

2.1.23 posix_spawnattr_getschedpolicy

Function Prototype:

Description: The posix_spawnattr_getschedpolicy() function will obtain the value of the spawn-schedpolicy attribute from the attributes object referenced by attr.

Input Parameters:

Returned Value: On success, this function returns 0; on failure it will return an error number from <errno.h>

2.1.24 posix_spawnattr_getsigmask

Function Prototype:

Description: The posix_spawnattr_getsigdefault() function will obtain the value of the spawn-sigmask attribute from the attributes object referenced by attr.

Input Parameters:

Returned Value: On success, this function returns 0; on failure it will return an error number from <errno.h>

2.1.25 posix_spawnattr_setflags

Function Prototype:

Description: The posix_spawnattr_setflags() function will set the spawn-flags attribute in an initialized attributes object referenced by attr.

Input Parameters:

Returned Value: On success, this function returns 0; on failure it will return an error number from <errno.h>

2.1.26 posix_spawnattr_setschedparam

Function Prototype:

Description: The posix_spawnattr_setschedparam() function will set the spawn-schedparam attribute in an initialized attributes object referenced by attr.

Input Parameters:

Returned Value: On success, this function returns 0; on failure it will return an error number from <errno.h>

2.1.27 posix_spawnattr_setschedpolicy

Function Prototype:

Description: The posix_spawnattr_setschedpolicy() function will set the spawn-schedpolicy attribute in an initialized attributes object referenced by attr.

Input Parameters:

Returned Value: On success, this function returns 0; on failure it will return an error number from <errno.h>

2.1.28 posix_spawnattr_setsigmask

Function Prototype:

Description: The posix_spawnattr_setsigmask() function will set the spawn-sigmask attribute in an initialized attributes object referenced by attr.

Input Parameters:

Returned Value: On success, this function returns 0; on failure it will return an error number from <errno.h>

2.1.29 task_spawn

Function Prototype:

Description: The task_spawn() function will create a new, child task, where the entry point to the task is an address in memory.

Returned Value: task_spawn() will return zero on success. Otherwise, an error number will be returned as the function return value to indicate the error:

POSIX Compatibility: This is a non-standard interface inspired by posix_spawn().

2.1.30 task_spawnattr_getstacksize

Function Prototype:

Description: The task_spawnattr_getstacksize() function will obtain the value of the spawn-stacksize attribute from the attributes object referenced by attr.

Input Parameters:

Returned Value: On success, this function returns 0; on failure it will return an error number from <errno.h>

2.1.31 task_spawnattr_setstacksize

Function Prototype:

Description: The task_spawnattr_setstacksize() function will set the spawn-stacksize attribute in an initialized attributes object referenced by attr.

Input Parameters:

Returned Value: On success, this function returns 0; on failure it will return an error number from <errno.h>

2.1.32 posix_spawn_file_actions_init

Function Prototype:

Description: The posix_spawn_file_actions_init() function initializes the object referenced by file_actions to an empty set of file actions for subsequent use in a call to posix_spawn() or posix_spawnp().

Input Parameters:

Returned Value: On success, this function returns 0; on failure it will return an error number from <errno.h>.

2.2 Task Scheduling Interfaces

By default, NuttX performs strict priority scheduling: Tasks of higher priority have exclusive access to the CPU until they become blocked. At that time, the CPU is available to tasks of lower priority. Tasks of equal priority are scheduled FIFO.

Optionally, a Nuttx task or thread can be configured with round-robin or sporadic scheduler. The round-robin is similar to priority scheduling except that tasks with equal priority and share CPU time via time-slicing. The time-slice interval is a constant determined by the configuration setting CONFIG_RR_INTERVAL to a positive, non-zero value. Sporadic scheduling scheduling is more complex, varying the priority of a thread over a replenishment period. Support for sporadic scheduling is enabled by the configuration option CONFIG_SCHED_SPORADIC.

The OS interfaces described in the following paragraphs provide a POSIX- compliant interface to the NuttX scheduler:

2.2.1 sched_setparam

Function Prototype: 

    #include <sched.h>
    int sched_setparam(pid_t pid, FAR const struct sched_param *param);

Description: This function sets the priority of the task specified by pid input parameter.

NOTE: Setting a task's priority to the same value has the similar effect to sched_yield(): The task will be moved to after all other tasks with the same priority.

Input Parameters:

Returned Value: On success, sched_setparam() returns 0 (OK). On error, -1 (ERROR) is returned, and errno is set appropriately.

Assumptions/Limitations:

POSIX Compatibility: Comparable to the POSIX interface of the same name. Differences from the full POSIX implementation include:

2.2.2 sched_getparam

Function Prototype: 

    #include <sched.h>
    int sched_getparam(pid_t pid, FAR struct sched_param *param);

Description: This function gets the scheduling priority of the task specified by pid.

Input Parameters:

Returned Value:

Assumptions/Limitations:

POSIX Compatibility: Comparable to the POSIX interface of the same name.

2.2.3 sched_setscheduler

Function Prototype:

Description: sched_setscheduler() sets both the scheduling policy and the priority for the task identified by pid. If pid equals zero, the scheduler of the calling thread will be set. The parameter param holds the priority of the thread under the new policy.

Input Parameters:

Returned Value: On success, sched_setscheduler() returns OK (zero). On error, ERROR (-1) is returned, and errno is set appropriately:

Assumptions/Limitations:

POSIX Compatibility: Comparable to the POSIX interface of the same name.

2.2.4 sched_getscheduler

Function Prototype:

Description: sched_getscheduler() returns the scheduling policy currently applied to the task identified by pid. If pid equals zero, the policy of the calling process will be retrieved.

Input Parameters:

Returned Value:

Assumptions/Limitations:

POSIX Compatibility: Comparable to the POSIX interface of the same name.

2.2.5 sched_yield

Function Prototype: 

    #include <sched.h>
    int sched_yield(void);

Description: This function forces the calling task to give up the CPU (only to other tasks at the same priority).

Input Parameters: None.

Returned Value:

Assumptions/Limitations:

POSIX Compatibility: Comparable to the POSIX interface of the same name.

2.2.6 sched_get_priority_max

Function Prototype: 

    #include <sched.h>
    int sched_get_priority_max (int policy)

Description: This function returns the value of the highest possible task priority for a specified scheduling policy.

Input Parameters:

Returned Value:

Assumptions/Limitations:

POSIX Compatibility: Comparable to the POSIX interface of the same name.

2.2.7 sched_get_priority_min

Function Prototype: 

    #include <sched.h>
    int sched_get_priority_min (int policy);

Description: This function returns the value of the lowest possible task priority for a specified scheduling policy.

Input Parameters:

Returned Value:

Assumptions/Limitations:

POSIX Compatibility: Comparable to the POSIX interface of the same name.

2.2.8 sched_get_rr_interval

Function Prototype: 

    #include <sched.h>
    int sched_get_rr_interval (pid_t pid, struct timespec *interval);

Description: sched_rr_get_interval() writes the timeslice interval for task identified by pid into the timespec structure pointed to by interval. If pid is zero, the timeslice for the calling process is written into 'interval. The identified process should be running under the SCHED_RR scheduling policy.'

Input Parameters:

Returned Value: On success, sched_rr_get_interval() returns OK (0). On error, ERROR (-1) is returned, and errno is set to:

Assumptions/Limitations:

POSIX Compatibility: Comparable to the POSIX interface of the same name.

2.3 Task Control Interfaces

Task Control Interfaces.

Parent and Child Tasks. The task synchronization interfaces historically depend upon parent and child relationships between tasks. But default, NuttX does not use any parent/child knowledge. However, there are three important configuration options that can change that.

Warning: If you enable the CONFIG_SCHED_CHILD_STATUS feature, then your application must either (1) take responsibility for reaping the child status with wait(), waitpid() or waitid(), or (2) suppress retention of child status. If you do not reap the child status, then you have a memory leak and your system will eventually fail.

Retention of child status can be suppressed on the parent using logic like:

2.3.1 sched_lock

Function Prototype: 

    #include <sched.h>
    int sched_lock(void);

Description: This function disables context switching by Disabling addition of new tasks to the ready-to-run task list. The task that calls this function will be the only task that is allowed to run until it either calls sched_unlock (the appropriate number of times) or until it blocks itself.

Input Parameters: None.

Returned Value:

Assumptions/Limitations:

POSIX Compatibility: This is a NON-POSIX interface. VxWorks provides the comparable interface: 

    STATUS taskLock(void);

2.3.2 sched_unlock

Function Prototype: 

    #include <sched.h>
    int sched_unlock(void);

Description: This function decrements the preemption lock count. Typically this is paired with sched_lock() and concludes a critical section of code. Preemption will not be unlocked until sched_unlock() has been called as many times as sched_lock(). When the lockCount is decremented to zero, any tasks that were eligible to preempt the current task will execute.

Input Parameters: None.

Returned Value:

Assumptions/Limitations:

POSIX Compatibility: This is a NON-POSIX interface. VxWorks provides the comparable interface: 

    STATUS taskUnlock(void);

2.3.3 sched_lockcount

Function Prototype: 

    #include <sched.h>
    int32_t sched_lockcount(void)

Description: This function returns the current value of the lockCount. If zero, preemption is enabled; if non-zero, this value indicates the number of times that sched_lock() has been called on this thread of execution.

Input Parameters: None.

Returned Value:

Assumptions/Limitations:

POSIX Compatibility: None.

2.3.4 waitpid

Function Prototype: 

    #include <sys/wait.h>
    ipid_t waitpid(pid_t pid, int *stat_loc, int options);

Description:

The following discussion is a general description of the waitpid() interface. However, as of this writing, the implementation of waitpid() is incomplete (but usable). If CONFIG_SCHED_HAVE_PARENT is defined, waitpid() will be a little more compliant to specifications. Without CONFIG_SCHED_HAVE_PARENT, waitpid() simply supports waiting for any task to complete execution. With CONFIG_SCHED_HAVE_PARENT, waitpid() will use SIGCHLD and can, therefore, wait for any child of the parent to complete. The implementation is incomplete in either case, however: NuttX does not support any concept of process groups. Nor does NuttX retain the status of exited tasks so if waitpid() is called after a task has exited, then no status will be available. The options argument is currently ignored.

The waitpid() functions will obtain status information pertaining to one of the caller's child processes. The waitpid() function will suspend execution of the calling thread until status information for one of the terminated child processes of the calling process is available, or until delivery of a signal whose action is either to execute a signal-catching function or to terminate the process. If more than one thread is suspended in waitpid() awaiting termination of the same process, exactly one thread will return the process status at the time of the target process termination. If status information is available prior to the call to waitpid(), return will be immediate.

NOTE: Because waitpid() is not fully POSIX compliant, it must be specifically enabled by setting CONFIG_SCHED_WAITPID in the NuttX configuration file.

Input Parameters:

The pid argument specifies a set of child processes for which status is requested. The waitpid() function will only return the status of a child process from this set:

The options argument is constructed from the bitwise-inclusive OR of zero or more of the following flags, defined in the <sys/wait.h> header:

If the calling process has SA_NOCLDWAIT set or has SIGCHLD set to SIG_IGN, and the process has no unwaited-for children that were transformed into zombie processes, the calling thread will block until all of the children of the process containing the calling thread terminate, and waitpid() will fail and set errno to ECHILD.

If waitpid() returns because the status of a child process is available, these functions will return a value equal to the process ID of the child process. In this case, if the value of the argument stat_loc is not a null pointer, information will be stored in the location pointed to by stat_loc. The value stored at the location pointed to by stat_loc will be 0 if and only if the status returned is from a terminated child process that terminated by one of the following means:

  1. The process returned 0 from main().
  2. The process called _exit() or exit() with a status argument of 0.
  3. The process was terminated because the last thread in the process terminated.

Regardless of its value, this information may be interpreted using the following macros, which are defined in <sys/wait.h> and evaluate to integral expressions; the stat_val argument is the integer value pointed to by stat_loc.

Returned Value:

If waitpid() returns because the status of a child process is available, it will return a value equal to the process ID of the child process for which status is reported.

If waitpid() returns due to the delivery of a signal to the calling process, -1 will be returned and errno set to EINTR.

If waitpid() was invoked with WNOHANG set in options, it has at least one child process specified by pid for which status is not available, and status is not available for any process specified by pid, 0 is returned.

Otherwise, (pid_t)-1errno set to indicate the error:

Assumptions/Limitations:

POSIX Compatibility: Comparable to the POSIX interface of the same name, but the implementation is incomplete (as detailed above).

2.3.5 waitid

Function Prototype: 

    #include <sys/wait.h>
    #ifdef CONFIG_SCHED_HAVE_PARENT
    int waitid(idtype_t idtype, id_t id, FAR siginfo_t *info, int options);
    #endif

Description:

The following discussion is a general description of the waitid() interface. However, as of this writing, the implementation of waitid() is incomplete (but usable). If CONFIG_SCHED_HAVE_PARENT is defined, waitid() will be a little more compliant to specifications. waitpid() simply supports waiting a specific child task (P_PID or for any child task P_ALL to complete execution. SIGCHLD is used. The implementation is incomplete in either case, however: NuttX does not support any concept of process groups. Nor does NuttX retain the status of exited tasks so if waitpid() is called after a task has exited, then no status will be available. The options argument is currently ignored.

The waitid() function suspends the calling thread until one child of the process containing the calling thread changes state. It records the current state of a child in the structure pointed to by info. If a child process changed state prior to the call to waitid(), waitid() returns immediately. If more than one thread is suspended in wait() or waitpid() waiting termination of the same process, exactly one thread will return the process status at the time of the target process termination

The idtype and id arguments are used to specify which children waitid() will wait for.

The options argument is used to specify which state changes waitid() will will wait for. It is formed by OR-ing together one or more of the following flags:

The info argument must point to a siginfo_t structure. If waitid() returns because a child process was found that satisfied the conditions indicated by the arguments idtype and options, then the structure pointed to by info will be filled in by the system with the status of the process. The si_signo member will always be equal to SIGCHLD.

Input Parameters: See the description above.

Returned Value: If waitid() returns due to the change of state of one of its children, 0 is returned. Otherwise, -1 is returned and errno is set to indicate the error.

The waitid() function will fail if:

Assumptions/Limitations:

POSIX Compatibility: Comparable to the POSIX interface of the same name, but the implementation is incomplete (as detailed in the description above).

2.3.6 wait

Function Prototype: 

    #include <sys/wait.h>
    #ifdef CONFIG_SCHED_HAVE_PARENT
    pid_t wait(FAR int *stat_loc);
    #endif

Description:

The following discussion is a general description of the wait() interface. However, as of this writing, the implementation of wait() is incomplete (but usable). wait() is based on waitpaid(). See the description of waitpaid() for further information.

The wait() function will suspend execution of the calling thread until status information for one of its terminated child processes is available, or until delivery of a signal whose action is either to execute a signal-catching function or to terminate the process. If more than one thread is suspended in wait() awaiting termination of the same process, exactly one thread will return the process status at the time of the target process termination. If status information is available prior to the call towait(), return will be immediate.

The waitpid() function will behave identically to wait(), if its pid argument is (pid_t)-1 and the options argument is 0. Otherwise, its behavior will be modified by the values of the pid and options arguments.

Input Parameters:

Returned Value: See the values returned by waitpaid().

Assumptions/Limitations:

POSIX Compatibility: Comparable to the POSIX interface of the same name, but the implementation is incomplete (as detailed in the description waitpaid()).

2.3.7 atexit

Function Prototype: 

    #include <stdlib.h>
    int atexit(void (*func)(void));

Description: Registers a function to be called at program exit. The atexit() function registers the given function to be called at normal process termination, whether via exit() or via return from the program's main().

NOTE: CONFIG_SCHED_ATEXIT must be defined to enable this function.

Input Parameters:

Returned Value: On success, atexit() returns OK (0). On error, ERROR (-1) is returned, and errno is set to indicate the cause of the failure.

Assumptions/Limitations:

POSIX Compatibility: Comparable to the ISO C interface of the same name. Limitations in the current implementation:

  1. Only a single atexit function can be registered unless CONFIG_SCHED_ATEXIT_MAX defines a larger number.
  2. atexit() functions are not inherited when a new task is created.

2.3.8 on_exit

Function Prototype: 

    #include <stdlib.h>
    int on_exit(CODE void (*func)(int, FAR void *), FAR void *arg)

Description: Registers a function to be called at program exit. The on_exit() function registers the given function to be called at normal process termination, whether via exit() or via return from the program's main(). The function is passed the status argument given to the last call to exit() and the arg argument from on_exit().

NOTE: CONFIG_SCHED_ONEXIT must be defined to enable this function

Input Parameters:

Returned Value: On success, on_exit() returns OK (0). On error, ERROR (-1) is returned, and errno is set to indicate the cause of the failure.

Assumptions/Limitations:

POSIX Compatibility: This function comes from SunOS 4, but is also present in libc4, libc5 and glibc. It no longer occurs in Solaris (SunOS 5). Avoid this function, and use the standard atexit() instead.

  1. Only a single on_exit function can be registered unless CONFIG_SCHED_ONEXIT_MAX defines a larger number.
  2. on_exit() functions are not inherited when a new task is created.

2.4 Named Message Queue Interfaces

NuttX supports POSIX named message queues for inter-task communication. Any task may send or receive messages on named message queues. Interrupt handlers may send messages via named message queues.

2.4.1 mq_open

Function Prototype: 

    #include <mqueue.h>
    mqd_t mq_open(const char *mqName, int oflags, ...);

Description: This function establish a connection between a named message queue and the calling task. After a successful call of mq_open(), the task can reference the message queue using the address returned by the call. The message queue remains usable until it is closed by a successful call to mq_close().

Input Parameters:

Returned Value:

Assumptions/Limitations:

POSIX Compatibility: Comparable to the POSIX interface of the same name. Differences from the full POSIX implementation include:

2.4.2 mq_close

Function Prototype: 

    #include <mqueue.h>
    int mq_close(mqd_t mqdes);

Description: This function is used to indicate that the calling task is finished with the specified message queued mqdes. The mq_close() deallocates any system resources allocated by the system for use by this task for its message queue.

If the calling task has attached a notification request to the message queue via this mqdes (see mq_notify()), this attachment will be removed and the message queue is available for another task to attach for notification.

Input Parameters:

Returned Value:

Assumptions/Limitations:

POSIX Compatibility: Comparable to the POSIX interface of the same name.

2.4.3 mq_unlink

Function Prototype: 

    #include <mqueue.h>
    int mq_unlink(const char *mqName);

Description: This function removes the message queue named by "mqName." If one or more tasks have the message queue open when mq_unlink() is called, removal of the message queue is postponed until all references to the message queue have been closed.

Input Parameters:

Returned Value: None.

Assumptions/Limitations:

POSIX Compatibility: Comparable to the POSIX interface of the same name.

2.4.4 mq_send

Function Prototype: 

    #include <mqueue.h>
    int mq_send(mqd_t mqdes, const void *msg, size_t msglen, int prio);

Description: This function adds the specified message, msg, to the message queue, mqdes. The msglen parameter specifies the length of the message in bytes pointed to by msg. This length must not exceed the maximum message length from the mq_getattr().

If the message queue is not full, mq_send() will place the msg in the message queue at the position indicated by the prio argument. Messages with higher priority will be inserted before lower priority messages The value of prio must not exceed MQ_PRIO_MAX.

If the specified message queue is full and O_NONBLOCK is not set in the message queue, then mq_send() will block until space becomes available to the queue the message.

If the message queue is full and NON_BLOCK is set, the message is not queued and ERROR is returned.

NOTE: mq_send() may be called from an interrupt handler. However, it behaves differently when called from the interrupt level:

Input Parameters:

Returned Value: On success, mq_send() returns 0 (OK); on error, -1 (ERROR) is returned, with errno set to indicate the error:

Assumptions/Limitations:

POSIX Compatibility: Comparable to the POSIX interface of the same name.

mq_timedsend

Function Prototype: 

    #include <mqueue.h>
    int mq_timedsend(mqd_t mqdes, const char *msg, size_t msglen, int prio,
                     const struct timespec *abstime);

Description: This function adds the specified message, msg, to the message queue, mqdes. The msglen parameter specifies the length of the message in bytes pointed to by msg. This length must not exceed the maximum message length from the mq_getattr().

If the message queue is not full, mq_timedsend() will place the msg in the message queue at the position indicated by the prio argument. Messages with higher priority will be inserted before lower priority messages The value of prio must not exceed MQ_PRIO_MAX.

If the specified message queue is full and O_NONBLOCK is not set in the message queue, then mq_send() will block until space becomes available to the queue the message or until a timeout occurs.

mq_timedsend() behaves just like mq_send(), except that if the queue is full and the O_NONBLOCK flag is not enabled for the message queue description, then abstime points to a structure which specifies a ceiling on the time for which the call will block. This ceiling is an absolute timeout in seconds and nanoseconds since the Epoch (midnight on the morning of 1 January 1970).

If the message queue is full, and the timeout has already expired by the time of the call, mq_timedsend() returns immediately.

Input Parameters:

Returned Value: On success, mq_send() returns 0 (OK); on error, -1 (ERROR) is returned, with errno set to indicate the error:

Assumptions/Limitations:

POSIX Compatibility: Comparable to the POSIX interface of the same name.

2.4.5 mq_receive

Function Prototype: 

    #include <mqueue.h>
    ssize_t mq_receive(mqd_t mqdes, void *msg, size_t msglen, int *prio);

Description: This function receives the oldest of the highest priority messages from the message queue specified by mqdes. If the size of the buffer in bytes, msgLen, is less than the mq_msgsize attribute of the message queue, mq_receive() will return an error. Otherwise, the selected message is removed from the queue and copied to msg.

If the message queue is empty and O_NONBLOCK was not set, mq_receive() will block until a message is added to the message queue. If more than one task is waiting to receive a message, only the task with the highest priority that has waited the longest will be unblocked.

If the queue is empty and O_NONBLOCK is set, ERROR will be returned.

Input Parameters:

Returned Value:. One success, the length of the selected message in bytes is returned. On failure, -1 (ERROR) is returned and the errno is set appropriately:

Assumptions/Limitations:

POSIX Compatibility: Comparable to the POSIX interface of the same name.

2.4.6 mq_timedreceive

Function Prototype: 

    #include <mqueue.h>
    ssize_t mq_timedreceive(mqd_t mqdes, void *msg, size_t msglen,
                            int *prio, const struct timespec *abstime);

Description: This function receives the oldest of the highest priority messages from the message queue specified by mqdes. If the size of the buffer in bytes, msgLen, is less than the mq_msgsize attribute of the message queue, mq_timedreceive() will return an error. Otherwise, the selected message is removed from the queue and copied to msg.

If the message queue is empty and O_NONBLOCK was not set, mq_timedreceive() will block until a message is added to the message queue (or until a timeout occurs). If more than one task is waiting to receive a message, only the task with the highest priority that has waited the longest will be unblocked.

mq_timedreceive() behaves just like mq_receive(), except that if the queue is empty and the O_NONBLOCK flag is not enabled for the message queue description, then abstime points to a structure which specifies a ceiling on the time for which the call will block. This ceiling is an absolute timeout in seconds and nanoseconds since the Epoch (midnight on the morning of 1 January 1970).

If no message is available, and the timeout has already expired by the time of the call, mq_timedreceive() returns immediately.

Input Parameters:

Returned Value:. One success, the length of the selected message in bytes is returned. On failure, -1 (ERROR) is returned and the errno is set appropriately:

Assumptions/Limitations:

POSIX Compatibility: Comparable to the POSIX interface of the same name.

2.4.7 mq_notify

Function Prototype: 

    #include <mqueue.h>
    int mq_notify(mqd_t mqdes, FAR const struct sigevent *notification);

Description: If the notification input parameter is not NULL, this function connects the task with the message queue such that the specified signal will be sent to the task whenever the message changes from empty to non-empty. One notification can be attached to a message queue.

If notification; is NULL, the attached notification is detached (if it was held by the calling task) and the queue is available to attach another notification.

When the notification is sent to the registered task, its registration will be removed. The message queue will then be available for registration.

Input Parameters:

Returned Value: On success mq_notify() returns 0; on error, -1 is returned, with errno set to indicate the error:

Assumptions/Limitations:

POSIX Compatibility: Comparable to the POSIX interface of the same name. Differences from the full POSIX implementation include:

2.4.8 mq_setattr

Function Prototype: 

    #include <mqueue.h>
    int mq_setattr(mqd_t mqdes, const struct mq_attr *mqStat,
                   struct mq_attr *oldMqStat);

Description: This function sets the attributes associated with the specified message queue "mqdes." Only the "O_NONBLOCK" bit of the "mq_flags" can be changed.

If "oldMqStat" is non-null, mq_setattr() will store the previous message queue attributes at that location (just as would have been returned by mq_getattr()).

Input Parameters:

Returned Value:

Assumptions/Limitations:

POSIX Compatibility: Comparable to the POSIX interface of the same name.

2.4.9 mq_getattr

Function Prototype: 

    #include <mqueue.h>
    int mq_getattr(mqd_t mqdes, struct mq_attr *mqStat);

Description: This functions gets status information and attributes associated with the specified message queue.

Input Parameters:

Returned Value:

Assumptions/Limitations:

POSIX Compatibility: Comparable to the POSIX interface of the same name.

2.5 Counting Semaphore Interfaces

Semaphores. Semaphores are the basis for synchronization and mutual exclusion in NuttX. NuttX supports POSIX semaphores.

Semaphores are the preferred mechanism for gaining exclusive access to a resource. sched_lock() and sched_unlock() can also be used for this purpose. However, sched_lock() and sched_unlock() have other undesirable side-effects in the operation of the system: sched_lock() also prevents higher-priority tasks from running that do not depend upon the semaphore-managed resource and, as a result, can adversely affect system response times.

Priority Inversion. Proper use of semaphores avoids the issues of sched_lock(). However, consider the following example:

  1. Some low-priority task, Task C, acquires a semaphore in order to get exclusive access to a protected resource.
  2. Task C is suspended to allow some high-priority task,
    3. Task A, to execute.
  3. Task A attempts to acquire the semaphore held by Task C and gets blocked until Task C relinquishes the semaphore.
  4. Task C is allowed to execute again, but gets suspended by some medium-priority Task B.

At this point, the high-priority Task A cannot execute until Task B (and possibly other medium-priority tasks) completes and until Task C relinquishes the semaphore. In effect, the high-priority task, Task A behaves as though it were lower in priority than the low-priority task, Task C! This phenomenon is called priority inversion.

Some operating systems avoid priority inversion by automatically increasing the priority of the low-priority Task C (the operable buzz-word for this behavior is priority inheritance). NuttX supports this behavior, but only if CONFIG_PRIORITY_INHERITANCE is defined in your OS configuration file. If CONFIG_PRIORITY_INHERITANCE is not defined, then it is left to the designer to provide implementations that will not suffer from priority inversion. The designer may, as examples:

Priority Inheritance. As mentioned, NuttX does support priority inheritance provided that CONFIG_PRIORITY_INHERITANCE is defined in your OS configuration file. However, the implementation and configuration of the priority inheritance feature is sufficiently complex that more needs to be said. How can a feature that can be described by a single, simple sentence require such a complex implementation:

Locking versus Signaling Semaphores. Semaphores (and mutexes) may be used for many different purposes. One typical use is for mutual exclusion and locking of resources: In this usage, the thread that needs exclusive access to a resources takes the semaphore to get access to the resource. The same thread subsequently releases the semaphore count when it no longer needs exclusive access. Priority inheritance is intended just for this usage case.

In a different usage case, a semaphore may to be used to signal an event: One thread A waits on a semaphore for an event to occur. When the event occurs, another thread B will post the semaphore waking the waiting thread A. This is a completely different usage model; notice that in the mutual exclusion case, the same thread takes and posts the semaphore. In the signaling case, one thread takes the semaphore and a different thread posts the semaphore. Priority inheritance should never be used in this signaling case. Subtle, strange behaviors may result.

When priority inheritance is enabled with CONFIG_PRIORITY_INHERITANCE, the default protocol for the semaphore will be to use priority inheritance. For signaling semaphores, priority inheritance must be explicitly disabled by calling sem_setprotocol with SEM_PRIO_NONE. For the case of pthread mutexes, pthread_mutexattr_setprotocol with PTHREAD_PRIO_NONE.

This is discussed in much more detail on this Wiki page.

POSIX semaphore interfaces:

2.5.1 sem_init

Function Prototype: 

    #include <semaphore.h>
    int sem_init(sem_t *sem, int pshared, unsigned int value);

Description: This function initializes the UN-NAMED semaphore sem. Following a successful call to sem_init(), the semaphore may be used in subsequent calls to sem_wait(), sem_post(), and sem_trywait(). The semaphore remains usable until it is destroyed.

Only sem itself may be used for performing synchronization. The result of referring to copies of sem in calls to sem_wait(), sem_trywait(), sem_post(), and sem_destroy(), is not defined.

Input Parameters:

Returned Value:

Assumptions/Limitations:

POSIX Compatibility: Comparable to the POSIX interface of the same name. Differences from the full POSIX implementation include:

2.5.2 sem_destroy

Function Prototype: 

    #include <semaphore.h>
    int sem_destroy(sem_t *sem);

Description: This function is used to destroy the un-named semaphore indicated by sem. Only a semaphore that was created using sem_init() may be destroyed using sem_destroy(). The effect of calling sem_destroy() with a named semaphore is undefined. The effect of subsequent use of the semaphore sem is undefined until sem is re-initialized by another call to sem_init().

The effect of destroying a semaphore upon which other tasks are currently blocked is undefined.

Input Parameters:

Returned Value:

Assumptions/Limitations:

POSIX Compatibility: Comparable to the POSIX interface of the same name.

2.5.3 sem_open

Function Prototype: 

    #include <semaphore.h>
    sem_t *sem_open(const char *name, int oflag, ...);

Description: This function establishes a connection between named semaphores and a task. Following a call to sem_open() with the semaphore name, the task may reference the semaphore associated with name using the address returned by this call. The semaphore may be used in subsequent calls to sem_wait(), sem_trywait(), and sem_post(). The semaphore remains usable until the semaphore is closed by a successful call to sem_close().

If a task makes multiple calls to sem_open() with the same name, then the same semaphore address is returned (provided there have been no calls to sem_unlink()).

Input Parameters:

Returned Value:

Assumptions/Limitations:

POSIX Compatibility: Comparable to the POSIX interface of the same name. Differences from the full POSIX implementation include:

2.5.4 sem_close

Function Prototype: 

    #include <semaphore.h>
    int sem_close(sem_t *sem);

Description: This function is called to indicate that the calling task is finished with the specified named semaphore, sem. The sem_close() deallocates any system resources allocated by the system for this named semaphore.

If the semaphore has not been removed with a call to sem_unlink(), then sem_close() has no effect on the named semaphore. However, when the named semaphore has been fully unlinked, the semaphore will vanish when the last task closes it.

Care must be taken to avoid risking the deletion of a semaphore that another calling task has already locked.

Input Parameters:

Returned Value:

Assumptions/Limitations:

POSIX Compatibility: Comparable to the POSIX interface of the same name.

2.5.5 sem_unlink

Function Prototype: 

    #include <semaphore.h>
    int sem_unlink(const char *name);

Description: This function will remove the semaphore named by the input name parameter. If one or more tasks have the semaphore named by name open when sem_unlink() is called, destruction of the semaphore will be postponed until all references have been destroyed by calls to sem_close().

Input Parameters:

Returned Value:

Assumptions/Limitations:

POSIX Compatibility: Comparable to the POSIX interface of the same name. Differences from the full POSIX implementation include:

2.5.6 sem_wait

Function Prototype: 

    #include <semaphore.h>
    int sem_wait(sem_t *sem);

Description: This function attempts to lock the semaphore referenced by sem. If the semaphore as already locked by another task, the calling task will not return until it either successfully acquires the lock or the call is interrupted by a signal.

Input Parameters:

Returned Value:

If sem_wait returns -1 (ERROR) then the cause of the failure will be indicated by the thread-specific errno. The following lists the possible values for errno:

Assumptions/Limitations:

POSIX Compatibility: Comparable to the POSIX interface of the same name.

2.5.7 sem_timedwait

Function Prototype: 

    #include <semaphore.h>
    int sem_timedwait(sem_t *sem, const struct timespec *abstime);

Description: This function will lock the semaphore referenced by sem as in the sem_wait() function. However, if the semaphore cannot be locked without waiting for another process or thread to unlock the semaphore by performing a sem_post() function, this wait will be terminated when the specified timeout expires.

The timeout will expire when the absolute time specified by abstime passes, as measured by the clock on which timeouts are based (that is, when the value of that clock equals or exceeds abstime), or if the absolute time specified by abstime has already been passed at the time of the call. This function attempts to lock the semaphore referenced by sem. If the semaphore is already locked by another task, the calling task will not return until it either successfully acquires the lock or the call is interrupted by a signal.

Input Parameters:

Returned Value:

If sem_timedwait returns -1 (ERROR) then the cause of the failure will be indicated by the thread-specific errno. The following lists the possible values for errno:

  • EINVAL: Indicates that the sem input parameter is not valid or the thread would have blocked, and the abstime parameter specified a nanoseconds field value less than zero or greater than or equal to 1000 million.
  • ETIMEDOUT: The semaphore could not be locked before the specified timeout expired.
  • EDEADLK: A deadlock condition was detected.
  • EINTR: Indicates that the wait was interrupt by a signal received by this task. In this case, the semaphore has not be acquired.

    • Assumptions/Limitations:

    POSIX Compatibility: Derived from IEEE Std 1003.1d-1999.

    2.5.8 sem_trywait

    Function Prototype: 

        #include <semaphore.h>
    int sem_trywait(sem_t *sem);

    Description: This function locks the specified semaphore only if the semaphore is currently not locked. In any event, the call returns without blocking.

    Input Parameters:

    Returned Value:

    If sem_trywait returns -1 (ERROR) then the cause of the failure will be indicated by the thread-specific errno. The following lists the possible values for errno:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.5.9 sem_post

    Function Prototype: 

        #include <semaphore.h>
    int sem_post(sem_t *sem);

    Description: When a task has finished with a semaphore, it will call sem_post(). This function unlocks the semaphore referenced by sem by performing the semaphore unlock operation.

    If the semaphore value resulting from this operation is positive, then no tasks were blocked waiting for the semaphore to become unlocked; The semaphore value is simply incremented.

    If the value of the semaphore resulting from this operation is zero, then on of the tasks blocked waiting for the semaphore will be allowed to return successfully from its call to sem_wait().

    NOTE: sem_post() may be called from an interrupt handler.

    Input Parameters:

    Returned Value:

    Assumptions/Limitations:. When called from an interrupt handler, it will appear as though the interrupt task is the one that is performing the unlock.

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.5.10 sem_getvalue

    Function Prototype: 

        #include <semaphore.h>
    int sem_getvalue(sem_t *sem, int *sval);

    Description: This function updates the location referenced by sval argument to have the value of the semaphore referenced by sem without effecting the state of the semaphore. The updated value represents the actual semaphore value that occurred at some unspecified time during the call, but may not reflect the actual value of the semaphore when it is returned to the calling task.

    If sem is locked, the value return by sem_getvalue() will either be zero or a negative number whose absolute value represents the number of tasks waiting for the semaphore.

    Input Parameters:

    Returned Value:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.5.11 sem_getprotocol

    Function Prototype: 

        #include <nuttx/semaphore.h>
    int sem_getprotocol(FAR const pthread_mutexattr_t *attr, FAR int *protocol);

    Description: Return the value of the semaphore protocol attribute.

    Input Parameters:

    Returned Value:

    If successful, the sem_getprotocol() function will return zero (OK). Otherwise, an -1 (ERROR) will be returned and the errno value will be set to indicate the nature of the error.

    Assumptions/Limitations:

    POSIX Compatibility: Non-standard NuttX interface. Should not be used in portable code. Analogous to pthread_muxtexattr_getprotocol().

    2.5.12 sem_setprotocol

    Function Prototype: 

        #include <nuttx/semaphore.h>
    int sem_setprotocol(FAR pthread_mutexattr_t *attr, int protocol);

    Description: Set semaphore protocol attribute. See the paragraph Locking versus Signaling Semaphores for some important information about the use of this interface.

    Input Parameters:

    Returned Value:

    If successful, the sem_setprotocol() function will return zero (OK). Otherwise, an -1 (ERROR) will be returned and the errno value will be set to indicate the nature of the error.

    Assumptions/Limitations:

    POSIX Compatibility: Non-standard NuttX interface. Should not be used in portable code. Analogous to pthread_muxtexattr_setprotocol().

    2.6 Clocks and Timers

    2.6.1 clock_settime

    Function Prototype: 

        #include <time.h>
    int clock_settime(clockid_t clockid, const struct timespec *tp);

    Description:

    Input Parameters:

    Returned Value: If successful, the clock_settime() function will return zero (OK). Otherwise, an non-zero error number will be returned to indicate the error:

    2.6.2 clock_gettime

    Function Prototype: 

        #include <time.h>
    int clock_gettime(clockid_t clockid, struct timespec *tp);

    Description:

    Input Parameters:

    Returned Value: If successful, the clock_gettime() function will return zero (OK). Otherwise, an non-zero error number will be returned to indicate the error:

    2.6.3 clock_getres

    Function Prototype: 

        #include <time.h>
    int clock_getres(clockid_t clockid, struct timespec *res);

    Description:

    Input Parameters:

    Returned Value: If successful, the clock_getres() function will return zero (OK). Otherwise, an non-zero error number will be returned to indicate the error:

    2.6.4 mktime

    Function Prototype: 

        #include <time.h>
    time_t mktime(struct tm *tp);

    Description:

    Input Parameters:

    Returned Value: If successful, the mktime() function will return zero (OK). Otherwise, an non-zero error number will be returned to indicate the error:

    2.6.5 gmtime

    Function Prototype: 

        #include <time.h>
    FAR struct tm *gmtime(FAR const time_t *timep);

    Description: Represents GMT date/time in a type struct tm. This function is not re-entrant.

    Input Parameters:

    Returned Value: If successful, the gmtime() function will return the pointer to a statically defined instance of struct tm. Otherwise, a NULL will be returned to indicate the error:

    2.6.6 localtime

    Description: Represents local date/time in a type struct tm. This function is not re-entrant.

    Input Parameters:

    Returned Value: Returned Value: If successful, the localtime() function will return the pointer to a statically defined instance of struct tm. Otherwise, a NULL will be returned to indicate the error:

    2.6.7 asctime

    Function Prototype:

    Description: asctime() convert the time provided in a struct tm to a string representation. asctime() is not re-entrant.

    Input Parameters:

    Returned Value: If successful, the asctime() function will return a pointer to a statically defined string holding the converted time. Otherwise, a NULL will be returned to indicate the error.

    2.6.8 ctime

    Function Prototype:

    Description: ctime() converts the time provided in seconds since the epoch to a string representation. ctime() is not re-entrant.

    Input Parameters:

    Returned Value: If successful, the ctime() function will return the pointer to the converted string. Otherwise, a NULL will be returned to indicate the error.

    2.6.9 gmtime_r

    Function Prototype: 

        #include <time.h>
    struct tm *gmtime_r(const time_t *timep, struct tm *result);

    Description: Represents GMT date/time in a type struct tm. This function is re-entrant.

    Input Parameters:

    Returned Value: If successful, the gmtime_r() function will return the pointer, result, provided by the caller. Otherwise, a NULL will be returned to indicate the error:

    2.6.10 localtime_r

    Description: Represents local date/time in a type struct tm. This function is re-entrant.

    Input Parameters:

    Returned Value: Returned Value: If successful, the localtime_r() function will return the pointer, result, provided by the caller. Otherwise, a NULL will be returned to indicate the error:

    2.6.11 asctime_r

    Function Prototype:

    Description: asctime_r() converts the time provided in a struct tm to a string representation. asctime-r() is re-entrant.

    Input Parameters:

    Returned Value: If successful, the asctime_r() function will return the pointer, buf, provided by the caller. Otherwise, a NULL will be returned to indicate the error.

    2.6.12 ctime_r

    Function Prototype:

    Description: ctime_r() converts the time provided in seconds since the epoch to a string representation. ctime() is re-entrant.

    Input Parameters:

    Returned Value: If successful, the ctime_r() function will return the pointer, buf, provided by the caller. Otherwise, a NULL will be returned to indicate the error.

    2.6.13 timer_create

    Function Prototype: 

        #include <time.h>
    int timer_create(clockid_t clockid, struct sigevent *evp, timer_t *timerid);

    Description: The timer_create() function creates per-thread timer using the specified clock, clock_id, as the timing base. The timer_create() function returns, in the location referenced by timerid, a timer ID of type timer_t used to identify the timer in timer requests. This timer ID is unique until the timer is deleted. The particular clock, clock_id, is defined in <time.h>. The timer whose ID is returned will be in a disarmed state upon return from timer_create().

    The evp argument, if non-NULL, points to a sigevent structure. This structure is allocated by the called and defines the asynchronous notification to occur. If the evp argument is NULL, the effect is as if the evp argument pointed to a sigevent structure with the sigev_notify member having the value SIGEV_SIGNAL, the sigev_signo having a default signal number, and the sigev_value member having the value of the timer ID.

    Each implementation defines a set of clocks that can be used as timing bases for per-thread timers. All implementations will support a clock_id of CLOCK_REALTIME.

    Input Parameters:

    Returned Value: If the call succeeds, timer_create() will return 0 (OK) and update the location referenced by timerid to a timer_t, which can be passed to the other per-thread timer calls. If an error occurs, the function will return a value of -1 (ERROR) and set errno to indicate the error.

    POSIX Compatibility: Comparable to the POSIX interface of the same name. Differences from the full POSIX implementation include:

    2.6.14 timer_delete

    Function Prototype: 

        #include <time.h>
    int timer_delete(timer_t timerid);

    Description: The timer_delete() function deletes the specified timer, timerid, previously created by the timer_create() function. If the timer is armed when timer_delete() is called, the timer will be automatically disarmed before removal. The disposition of pending signals for the deleted timer is unspecified.

    Input Parameters:

    Returned Value: If successful, the timer_delete() function will return zero (OK). Otherwise, the function will return a value of -1 (ERROR) and set errno to indicate the error:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.6.15 timer_settime

    Function Prototype: 

        #include <time.h>
    int timer_settime(timer_t timerid, int flags, const struct itimerspec *value,
                      struct itimerspec *ovalue);

    Description: The timer_settime() function sets the time until the next expiration of the timer specified by timerid from the it_value member of the value argument and arm the timer if the it_value member of value is non-zero. If the specified timer was already armed when timer_settime() is called, this call will reset the time until next expiration to the value specified. If the it_value member of value is zero, the timer will be disarmed. The effect of disarming or resetting a timer with pending expiration notifications is unspecified.

    If the flag TIMER_ABSTIME is not set in the argument flags, timer_settime() will behave as if the time until next expiration is set to be equal to the interval specified by the it_value member of value. That is, the timer will expire in it_value nanoseconds from when the call is made. If the flag TIMER_ABSTIME is set in the argument flags, timer_settime() will behave as if the time until next expiration is set to be equal to the difference between the absolute time specified by the it_value member of value and the current value of the clock associated with timerid. That is, the timer will expire when the clock reaches the value specified by the it_value member of value. If the specified time has already passed, the function will succeed and the expiration notification will be made.

    The reload value of the timer will be set to the value specified by the it_interval member of value. When a timer is armed with a non-zero it_interval, a periodic (or repetitive) timer is specified.

    Time values that are between two consecutive non-negative integer multiples of the resolution of the specified timer will be rounded up to the larger multiple of the resolution. Quantization error will not cause the timer to expire earlier than the rounded time value.

    If the argument ovalue is not NULL, the timer_settime() function will store, in the location referenced by ovalue, a value representing the previous amount of time before the timer would have expired, or zero if the timer was disarmed, together with the previous timer reload value. Timers will not expire before their scheduled time.

    NOTE:At present, the ovalue argument is ignored.

    Input Parameters:

    Returned Value: If the timer_gettime() succeeds, a value of 0 (OK) will be returned. If an error occurs, the value -1 (ERROR) will be returned, and errno set to indicate the error.

    POSIX Compatibility: Comparable to the POSIX interface of the same name. Differences from the full POSIX implementation include:

    2.6.16 timer_gettime

    Function Prototype: 

        #include <time.h>
    int timer_gettime(timer_t timerid, struct itimerspec *value);

    Description: The timer_gettime() function will store the amount of time until the specified timer, timerid, expires and the reload value of the timer into the space pointed to by the value argument. The it_value member of this structure will contain the amount of time before the timer expires, or zero if the timer is disarmed. This value is returned as the interval until timer expiration, even if the timer was armed with absolute time. The it_interval member of value will contain the reload value last set by timer_settime().

    Due to the asynchronous operation of this function, the time reported by this function could be significantly more than that actual time remaining on the timer at any time.

    Input Parameters:

    Returned Value: If successful, the timer_gettime() function will return zero (OK). Otherwise, an non-zero error number will be returned to indicate the error:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.6.17 timer_getoverrun

    Function Prototype: 

        #include <time.h>
    int timer_getoverrun(timer_t timerid);

    Description: Only a single signal will be queued to the process for a given timer at any point in time. When a timer for which a signal is still pending expires, no signal will be queued, and a timer overrun will occur. When a timer expiration signal is delivered to or accepted by a process, if the implementation supports the Realtime Signals Extension, the timer_getoverrun() function will return the timer expiration overrun count for the specified timer. The overrun count returned contains the number of extra timer expirations that occurred between the time the signal was generated (queued) and when it was delivered or accepted, up to but not including an implementation-defined maximum of DELAYTIMER_MAX. If the number of such extra expirations is greater than or equal to DELAYTIMER_MAX, then the overrun count will be set to DELAYTIMER_MAX. The value returned by timer_getoverrun() will apply to the most recent expiration signal delivery or acceptance for the timer. If no expiration signal has been delivered for the timer, or if the Realtime Signals Extension is not supported, the return value of timer_getoverrun() is unspecified.

    NOTE: This interface is not currently implemented in NuttX.

    Input Parameters:

    Returned Value: If the timer_getoverrun() function succeeds, it will return the timer expiration overrun count as explained above. timer_getoverrun() will fail if:

    POSIX Compatibility: Comparable to the POSIX interface of the same name. Differences from the full POSIX implementation include:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.6.18 gettimeofday

    Function Prototype: 

        #include <sys/time.h>
    int gettimeofday(struct timeval *tp, void *tzp);

    Description: This implementation of gettimeofday() is simply a thin wrapper around clock_gettime(). It simply calls clock_gettime() using the CLOCK_REALTIME timer and converts the result to the required struct timeval.

    Input Parameters:

    Returned Value: See clock_gettime().

    2.7 Signal Interfaces

    Tasks and Signals. NuttX provides signal interfaces for tasks and pthreads. Signals are used to alter the flow control of tasks by communicating asynchronous events within or between task contexts. Any task or interrupt handler can post (or send) a signal to a particular task using its task ID. The task being signaled will execute task-specified signal handler function the next time that the task has priority. The signal handler is a user-supplied function that is bound to a specific signal and performs whatever actions are necessary whenever the signal is received.

    By default, here are no predefined actions for any signal. The default action for all signals (i.e., when no signal handler has been supplied by the user) is to ignore the signal. In this sense, all NuttX are real time signals by default. If the configuration option CONFIG_SIG_DEFAULT=y is included, some signals will perform their default actions dependent upon addition configuration settings as summarized in the following table:

    Tasks may also suspend themselves and wait until a signal is received.

    Tasks Groups. NuttX supports both tasks and pthreads. The primary difference between tasks and pthreads is the tasks are much more independent. Tasks can create pthreads and those pthreads will share the resources of the task. The main task and its children pthreads together are referred as a task group. A task group is used in NuttX to emulate a POSIX process.

    NOTE: Behavior of features related to task groups depend of NuttX configuration settings. See also the NuttX Tasking page and the Tasks vs. Threads FAQ for additional information on tasks and threads in NuttX.

    Signaling Multi-threaded Task Groups. The behavior of signals in the multi-thread task group is complex. NuttX emulates a process model with task groups and follows the POSIX rules for signaling behavior. Normally when you signal the task group you would signal using the task ID of the main task that created the group (in practice, a different task should not know the IDs of the internal threads created within the task group); that ID is remembered by the task group (even if the main task thread exits).

    Here are some of the things that should happen when you signal a multi-threaded task group:

    You can mask out that signal using ''sigprocmask()'' (or ''pthread_sigmask()''). That signal will then be effectively disabled and will never be received in those threads that have the signal masked. On creation of a new thread, the new thread will inherit the signal mask of the parent thread that created it. So you if block signal signals on one thread then create new threads, those signals will also be blocked in the new threads as well.

    You can control which thread receives the signal by controlling the signal mask. You can, for example, create a single thread whose sole purpose it is to catch a particular signal and respond to it: Simply block the signal in the main task; then the signal will be blocked in all of the pthreads in the group too. In the one "signal processing" pthread, enable the blocked signal. This thread will then be only thread that will receive the signal.

    Signal Interfaces. The following signal handling interfaces are provided by NuttX:

    2.7.1 sigemptyset

    Function Prototype: 

        #include <signal.h>
    int sigemptyset(sigset_t *set);

    Description: This function initializes the signal set specified by set such that all signals are excluded.

    Input Parameters:

    Returned Value:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.7.2 sigfillset

    Function Prototype: 

        #include <signal.h>
    int sigfillset(sigset_t *set);

    Description: This function initializes the signal set specified by set such that all signals are included.

    Input Parameters:

    Returned Value:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.7.3 sigaddset

    Function Prototype: 

        #include <signal.h>
    int sigaddset(sigset_t *set, int signo);

    Description: This function adds the signal specified by signo to the signal set specified by set.

    Input Parameters:

    Returned Value:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.7.4 sigdelset

    Function Prototype: 

        #include <signal.h>
    int sigdelset(sigset_t *set, int signo);

    Description: This function deletes the signal specified by signo from the signal set specified by set.

    Input Parameters:

    Returned Value:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.7.5 sigismember

    Function Prototype: 

        #include <signal.h>
    int  sigismember(const sigset_t *set, int signo);

    Description: This function tests whether the signal specified by signo is a member of the set specified by set.

    Input Parameters:

    Returned Value:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.7.6 sigaction

    Function Prototype: 

        #include <signal.h>
    int sigaction(int signo, const struct sigaction *act,
                  struct sigaction *oact);

    Description: This function allows the calling task to examine and/or specify the action to be associated with a specific signal.

    The structure sigaction, used to describe an action to be taken, is defined to include the following members:

    If the argument act is not NULL, it points to a structure specifying the action to be associated with the specified signal. If the argument oact is not NULL, the action previously associated with the signal is stored in the location pointed to by the argument oact. If the argument act is NULL, signal handling is unchanged by this function call; thus, the call can be used to inquire about the current handling of a given signal.

    When a signal is caught by a signal-catching function installed by the sigaction() function, a new signal mask is calculated and installed for the duration of the signal-catching function. This mask is formed by taking the union of the current signal mask and the value of the sa_mask for the signal being delivered, and then including the signal being delivered. If and when the signal handler returns, the original signal mask is restored.

    Signal catching functions execute in the same address environment as the task that called sigaction() to install the signal-catching function.

    Once an action is installed for a specific signal, it remains installed until another action is explicitly requested by another call to sigaction().

    Input Parameters:

    Returned Value:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name. Differences from the POSIX implementation include:

    2.7.7 sigignore

    Function Prototype: 

        #include <signal.h>
    int sigignore(int signo);

    Description: The sigignore() function will set the disposition of signo to SIG_IGN.

    Input Parameters:

    Returned Value:

    2.7.8 sigset

    Function Prototype: 

        #include <signal.h>
    void (*sigset(int signo, void (*disp)(int)))(int);

    Description: The sigset() function will modify signal dispositions. The signo argument specifies the signal. The disp argument specifies the signal's disposition, which may be SIG_DFL, SIG_IGN, or the address of a signal handler. If disp is the address of a signal handler, the system will add signo to the calling process's signal mask before executing the signal handler; when the signal handler returns, the system will restore the calling process's signal mask to its state prior to the delivery of the signal. signo will be removed from the calling process's signal mask.

    NOTE: The value SIG_HOLD for disp is not currently supported.

    Input Parameters:

    Returned Value:

    2.7.9 sigprocmask

    Function Prototype: 

        #include <signal.h>
    int sigprocmask(int how, const sigset_t *set, sigset_t *oset);

    Description: This function allows the calling task to examine and/or change its signal mask. If the set is not NULL, then it points to a set of signals to be used to change the currently blocked set. The value of how indicates the manner in which the set is changed.

    If there are any pending unblocked signals after the call to sigprocmask(), those signals will be delivered before sigprocmask() returns.

    If sigprocmask() fails, the signal mask of the task is not changed.

    Input Parameters:

    Returned Value:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.7.10 sighold

    Function Prototype: 

        #include <signal.h>
    int sighold(int signo);

    Description: The sighold() function will add signo to the calling process's signal mask

    Input Parameters:

    Returned Value:

    2.7.11 sigrelse

    Function Prototype: 

        #include <signal.h>
    int sigrelse(int signo);

    Description: The sighold() function will remove signo from the calling process's signal mask

    Input Parameters:

    Returned Value:

    2.7.12 sigpending

    Function Prototype: 

        #include <signal.h>
    int sigpending(sigset_t *set);

    Description: This function stores the returns the set of signals that are blocked for delivery and that are pending for the calling task in the space pointed to by set.

    If the task receiving a signal has the signal blocked via its sigprocmask, the signal will pend until it is unmasked. Only one pending signal (for a given signo) is retained by the system. This is consistent with POSIX which states: "If a subsequent occurrence of a pending signal is generated, it is implementation defined as to whether the signal is delivered more than once."

    Input Parameters:

    Returned Value:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.7.13 sigsuspend

    Function Prototype: 

        #include <signal.h>
    int sigsuspend(const sigset_t *set);

    Description: The sigsuspend() function replaces the signal mask with the set of signals pointed to by the argument set and then suspends the task until delivery of a signal to the task.

    If the effect of the set argument is to unblock a pending signal, then no wait is performed.

    The original signal mask is restored when sigsuspend() returns.

    Waiting for an empty signal set stops a task without freeing any resources (a very bad idea).

    Input Parameters:

    Returned Value:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name. Differences from the POSIX specification include:

    2.7.14 sigpause

    Function Prototype: 

        #include <signal.h>
    int sigpause(int signo);

    Description: The sigpause()) function will remove signo) from the calling process's signal mask and suspend the calling process until a signal is received. The sigpause()) function will restore the process's signal mask to its original state before returning.

    Input Parameters:

    Returned Value:

    2.7.15 sigwaitinfo

    Function Prototype: 

        #include <signal.h>
    int sigwaitinfo(const sigset_t *set, struct siginfo *info);

    Description: This function is equivalent to sigtimedwait() with a NULL timeout parameter. (see below).

    Input Parameters:

    Returned Value:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.7.16 sigtimedwait

    Function Prototype: 

        #include <signal.h>
    int sigtimedwait(const sigset_t *set, struct siginfo *info,
                     const struct timespec *timeout);

    Description: This function selects the pending signal set specified by the argument set. If multiple signals are pending in set, it will remove and return the lowest numbered one. If no signals in set are pending at the time of the call, the calling task will be suspended until one of the signals in set becomes pending OR until the task interrupted by an unblocked signal OR until the time interval specified by timeout (if any), has expired. If timeout is NULL, then the timeout interval is forever.

    If the info argument is non-NULL, the selected signal number is stored in the si_signo member and the cause of the signal is store in the si_code member. The content of si_value is only meaningful if the signal was generated by sigqueue(). The following values for si_code are defined in signal.h:

    Input Parameters:

    Returned Value:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name. Differences from the POSIX interface include:

    2.7.17 sigqueue

    Function Prototype: 

        #include <signal.h>
    int sigqueue (int tid, int signo, union sigval value);

    Description: This function sends the signal specified by signo with the signal parameter value to the task specified by tid.

    If the receiving task has the signal blocked via its sigprocmask, the signal will pend until it is unmasked. Only one pending signal (for a given signo) is retained by the system. This is consistent with POSIX which states: "If a subsequent occurrence of a pending signal is generated, it is implementation defined as to whether the signal is delivered more than once."

    Input Parameters:

    Returned Value:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name. Differences from the POSIX interface include:

    2.7.18 kill

    Function Prototype: 

       #include <sys/types.h>
   #include <signal.h>
   int kill(pid_t pid, int sig);

    Description: The kill() system call can be used to send any signal to any task.

    If the receiving task has the signal blocked via its sigprocmask, the signal will pend until it is unmasked. Only one pending signal (for a given signo) is retained by the system. This is consistent with POSIX which states: "If a subsequent occurrence of a pending signal is generated, it is implementation defined as to whether the signal is delivered more than once."

    Input Parameters:

    Returned Value:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name. Differences from the POSIX interface include:

    2.7.19 pause

    Function Prototype: 

       #include <unistd.h>
   int pause(void);

    Description: The pause() function will suspend the calling thread until delivery of a non-blocked signal.

    Input Parameters:

    Returned Value: Since pause() suspends thread execution indefinitely unless interrupted a signal, there is no successful completion return value. A value of -1 (ERROR will always be returned and errno set to indicate the error (EINTR).

    Assumptions/Limitations:

    POSIX Compatibility: In the POSIX description of this function is the pause() function will suspend the calling thread until delivery of a signal whose action is either to execute a signal-catching function or to terminate the process. This implementation only waits for any non-blocked signal to be received.

    2.8 Pthread Interfaces

    NuttX does not support processes in the way that, say, Linux does. NuttX only supports simple threads or tasks running within the same address space. However, NuttX does support the concept of a task group. A task group is the functional analog of a process: It is a group that consists of the main task thread and of all of the pthreads created by the main thread or any of the other pthreads within the task group. Members of a task group share certain resources such as environment variables, file descriptors, FILE streams, sockets, pthread keys and open message queues.

    NOTE: Behavior of features related to task groups depend of NuttX configuration settings. See also the NuttX Tasking page and the Tasks vs. Threads FAQ for additional information on tasks and threads in NuttX.

    The following pthread interfaces are supported in some form by NuttX:

    No support for the following pthread interfaces is provided by NuttX:

    2.8.1 pthread_attr_init

    Function Prototype: 

        #include <pthread.h>
    int pthread_attr_init(pthread_attr_t *attr);

    Description: Initializes a thread attributes object (attr) with default values for all of the individual attributes used by the implementation.

    Input Parameters:

    Returned Value:

    If successful, the pthread_attr_init() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.2 pthread_attr_destroy

    Function Prototype: 

        #include <pthread.h>
    int pthread_attr_destroy(FAR pthread_attr_t *attr);

    Description: An attributes object can be deleted when it is no longer needed.

    Input Parameters:

    Returned Value:

    If successful, the pthread_attr_destroy() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.3 pthread_attr_setschedpolicy

    Function Prototype: 

        #include <pthread.h>
    int pthread_attr_setschedpolicy(pthread_attr_t *attr, int policy);

    Description:

    Input Parameters:

    Returned Value:

    If successful, the pthread_attr_setschedpolicy() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.4 pthread_attr_getschedpolicy

    Function Prototype: 

        #include <pthread.h>
    int pthread_attr_getschedpolicy(FAR const pthread_attr_t *attr, FAR int *policy);

    Description:

    Input Parameters:

    Returned Value:

    If successful, the pthread_attr_getschedpolicy() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.5 pthread_attr_getschedpolicy

    Function Prototype: 

        #include <pthread.h>
    int pthread_attr_setschedparam(pthread_attr_t *attr,
                                   const struct sched_param *param);

    Description:

    Input Parameters:

    Returned Value:

    If successful, the pthread_attr_getschedpolicy() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.6 pthread_attr_getschedparam

    Function Prototype: 

        #include <pthread.h>
    int pthread_attr_getschedparam(pthread_attr_t *attr,
                                   struct sched_param *param);

    Description:

    Input Parameters:

    Returned Value:

    If successful, the pthread_attr_getschedparam() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.7 pthread_attr_setinheritsched

    Function Prototype: 

       #include <pthread.h>
    int pthread_attr_setinheritsched(pthread_attr_t *attr,
                                     int inheritsched);

    Description:

    Input Parameters:

    Returned Value:

    If successful, the pthread_attr_setinheritsched() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.8 pthread_attr_getinheritsched

    Function Prototype: 

       #include <pthread.h>
     int pthread_attr_getinheritsched(const pthread_attr_t *attr,
                                      int *inheritsched);

    Description:

    Input Parameters:

    Returned Value:

    If successful, the pthread_attr_getinheritsched() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.9 pthread_attr_setstacksize

    Function Prototype: 

        #include <pthread.h>
    int pthread_attr_setstacksize(pthread_attr_t *attr, long stacksize);

    Description:

    Input Parameters:

    Returned Value:

    If successful, the pthread_attr_setstacksize() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.10 pthread_attr_getstacksize

    Function Prototype: 

        #include <pthread.h>
    int pthread_attr_getstacksize(FAR const pthread_attr_t *attr, FAR size_t *stackaddr);

    Description:

    Input Parameters:

    Returned Value:

    If successful, the pthread_attr_getstacksize() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.11 pthread_create

    Function Prototype: 

        #include <pthread.h>
    int pthread_create(pthread_t *thread, pthread_attr_t *attr,
                       pthread_startroutine_t startRoutine,
                       pthread_addr_t arg);

    Description: To create a thread object and runnable thread, a routine must be specified as the new thread's start routine. An argument may be passed to this routine, as an untyped address; an untyped address may also be returned as the routine's value. An attributes object may be used to specify details about the kind of thread being created.

    Input Parameters:

    Returned Value:

    If successful, the pthread_create() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.12 pthread_detach

    Function Prototype: 

        #include <pthread.h>
    int pthread_detach(pthread_t thread);

    Description: A thread object may be "detached" to specify that the return value and completion status will not be requested.

    Input Parameters:

    Returned Value:

    If successful, the pthread_detach() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.13 pthread_exit

    Function Prototype: 

        #include <pthread.h>
    void pthread_exit(pthread_addr_t pvValue);

    Description: A thread may terminate it's own execution.

    Input Parameters:

    Returned Value:

    If successful, the pthread_exit() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.14 pthread_cancel

    Function Prototype: 

        #include <pthread.h>
    int pthread_cancel(pthread_t thread);

    Description:

    The pthread_cancel() function will request that thread be canceled. The target thread's cancellability state, enabled, or disabled, determines when the cancellation takes effect: When the cancellation is acted on, thread will be terminated. When cancellability is disabled, all cancellations are held pending in the target thread until the thread re-enables cancellability.

    The target thread's cancellability state determines how the cancellation is acted on: Either asynchronously or deferred. Asynchronous cancellations will be acted upon immediately (when enabled), interrupting the thread with its processing in an arbitrary state.

    When cancellability is deferred, all cancellations are held pending in the target thread until the thread changes the cancellability type or a Cancellation Point function such as pthread_testcancel() is entered.

    Input Parameters:

    Returned Value:

    If successful, the pthread_cancel() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name. Except:

    2.8.15 pthread_setcancelstate

    Function Prototype: 

        #include <pthread.h>
    int pthread_setcancelstate(int state, int *oldstate);

    Description:

    The pthread_setcancelstate() function atomically sets both the calling thread's cancellability state to the indicated state and returns the previous cancellability state at the location referenced by oldstate. Legal values for state are PTHREAD_CANCEL_ENABLE and PTHREAD_CANCEL_DISABLE.

    Any pending thread cancellation may occur at the time that the cancellation state is set to PTHREAD_CANCEL_ENABLE.

    Input Parameters:

    Returned Value:

    If successful, the pthread_setcancelstate() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.16 pthread_setcanceltype

    Function Prototype: 

        #include <pthread.h>
    int pthread_setcanceltype(int type, FAR int *oldtype);

    Description: The pthread_setcanceltype() function atomically both sets the calling thread's cancellability type to the indicated type and returns the previous cancellability type at the location referenced by oldtype. Legal values for type are PTHREAD_CANCEL_DEFERRED and PTHREAD_CANCEL_ASYNCHRONOUS.

    The cancellability state and type of any newly created threads are PTHREAD_CANCEL_ENABLE and PTHREAD_CANCEL_DEFERRED respectively.

    Input Parameters:

    Returned Value:

    If successful, the pthread_setcancelstate() function will return zero (OK). Otherwise, an error number will be returned to indicate the error.

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.17 pthread_testcancel

    Function Prototype: 

        #include <pthread.h>
    void pthread_testcancel(void);

    Description:

    The pthread_testcancel() function creates a Cancellation Point in the calling thread. The pthread_testcancel() function has no effect if cancellability is disabled.

    Input Parameters: None

    Returned Value: None

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.18 pthread_cleanup_pop

    Function Prototype: 

        #include <pthread.h>
    void pthread_cleanup_pop(int execute);

    Description:

    The pthread_cleanup_pop() function will remove the routine at the top of the calling thread's cancellation cleanup stack and optionally invoke it (if execute is non-zero).

    Input Parameters:

    Returned Value:

    If successful, the pthread_setcancelstate() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.19 pthread_cleanup_push

    Function Prototype: 

        #include <pthread.h>
    void pthread_cleanup_push(CODE void (*routine)(FAR void *), FAR void *arg);

    Description:

    The pthread_cleanup_push() function will push the specified cancellation cleanup handler routine onto the calling thread's cancellation cleanup stack.

    The cancellation cleanup handler will be popped from the cancellation cleanup stack and invoked with the argument arg when:

    Input Parameters:

    Returned Value:

    If successful, the pthread_setcancelstate() function will return zero (OK). Otherwise, an error number will be returned to indicate the error.

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.20 pthread_join

    Function Prototype: 

        #include <pthread.h>
    int pthread_join(pthread_t thread, pthread_addr_t *ppvValue);

    Description: A thread can await termination of another thread and retrieve the return value of the thread.

    Input Parameters:

    Returned Value:

    If successful, the pthread_join() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.21 pthread_yield

    Function Prototype: 

        #include <pthread.h>
    void pthread_yield(void);

    Description: A thread may tell the scheduler that its processor can be made available.

    Input Parameters:

    Returned Value:

    Assumptions/Limitations:

    POSIX Compatibility: This call is nonstandard, but present on several other systems. Use the POSIX sched_yield() instead.

    2.8.22 pthread_self

    Function Prototype: 

        #include <pthread.h>
    pthread_t pthread_self(void);

    Description: A thread may obtain a copy of its own thread handle.

    Input Parameters:

    Returned Value:

    If successful, the pthread_self() function will return copy of caller's thread handle. Otherwise, in exceptional circumstances, the negated error code -ESRCH can be returned if the system cannot deduce the identity of the calling thread.

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name. The -ESRCH return value is non-standard; POSIX says pthread_self() must always succeed. NuttX implements pthread_self() as a macro only, not as a function as required by POSIX.

    2.8.23 pthread_getschedparam

    Function Prototype: 

        #include <pthread.h>
    int pthread_getschedparam(pthread_t thread, int *policy,
                              struct sched_param *param);

    Description: The pthread_getschedparam() functions will get the scheduling policy and parameters of threads. For SCHED_FIFO and SCHED_RR, the only required member of the sched_param structure is the priority sched_priority.

    The pthread_getschedparam() function will retrieve the scheduling policy and scheduling parameters for the thread whose thread ID is given by thread and will store those values in policy and param, respectively. The priority value returned from pthread_getschedparam() will be the value specified by the most recent pthread_setschedparam(), pthread_setschedprio(), or pthread_create() call affecting the target thread. It will not reflect any temporary adjustments to its priority (such as might result of any priority inheritance, for example).

    The policy parameter may have the value SCHED_FIFO, SCHED_RR, or SCHED_SPORADIC. SCHED_RR requires the configuration setting CONFIG_RR_INTERVAL > 0; SCHED_SPORADIC requires the configuration setting CONFIG_SCHED_SPORADIC=y. (SCHED_OTHER and non-standard scheduler policies, in particular, are not supported). The SCHED_FIFO and SCHED_RR policies will have a single scheduling parameter:

    The SCHED_SPORADIC policy has four additional scheduling parameters:

    Input Parameters:

    Returned Value: 0 (OK) if successful. Otherwise, the error code ESRCH if the value specified by thread does not refer to an existing thread.

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.24 pthread_setschedparam

    Function Prototype: 

        #include <pthread.h>
    int pthread_setschedparam(pthread_t thread, int policy,
                              const struct sched_param *param);

    Description: The pthread_setschedparam() functions will set the scheduling policy and parameters of threads. For SCHED_FIFO and SCHED_RR, the only required member of the sched_param structure is the priority sched_priority.

    The pthread_setschedparam() function will set the scheduling policy and associated scheduling parameters for the thread whose thread ID is given by thread to the policy and associated parameters provided in policy and param, respectively.

    The policy parameter may have the value SCHED_FIFO or SCHED_RR. (SCHED_OTHER and SCHED_SPORADIC, in particular, are not supported). The SCHED_FIFO and SCHED_RR policies will have a single scheduling parameter, sched_priority.

    If the pthread_setschedparam() function fails, the scheduling parameters will not be changed for the target thread.

    Input Parameters:

    Returned Value:

    If successful, the pthread_setschedparam() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.25 pthread_key_create

    Function Prototype: 

        #include <pthread.h>
    int pthread_key_create(pthread_key_t *key, void (*destructor)(void*))

    Description:

    This function creates a thread-specific data key visible to all threads in the system. Although the same key value may be used by different threads, the values bound to the key by pthread_setspecific() are maintained on a per-thread basis and persist for the life of the calling thread.

    Upon key creation, the value NULL will be associated with the new key in all active threads. Upon thread creation, the value NULL will be associated with all defined keys in the new thread.

    Input Parameters:

    Returned Value:

    If successful, the pthread_key_create() function will store the newly created key value at *key and return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.26 pthread_setspecific

    Function Prototype: 

        #include <pthread.h>
    int pthread_setspecific(pthread_key_t key, void *value)

    Description:

    The pthread_setspecific() function associates a thread-specific value with a key obtained via a previous call to pthread_key_create(). Different threads may bind different values to the same key. These values are typically pointers to blocks of dynamically allocated memory that have been reserved for use by the calling thread.

    The effect of calling pthread_setspecific() with a key value not obtained from pthread_key_create() or after a key has been deleted with pthread_key_delete() is undefined.

    Input Parameters:

    Returned Value:

    If successful, pthread_setspecific() will return zero (OK). Otherwise, an error number will be returned:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.27 pthread_getspecific

    Function Prototype: 

        #include <pthread.h>
    void *pthread_getspecific(pthread_key_t key)

    Description:

    The pthread_getspecific() function returns the value currently bound to the specified key on behalf of the calling thread.

    The effect of calling pthread_getspecific() with a key value not obtained from pthread_key_create() or after a key has been deleted with pthread_key_delete() is undefined.

    Input Parameters:

    Returned Value:

    The function pthread_getspecific() returns the thread-specific data associated with the given key. If no thread specific data is associated with the key, then the value NULL is returned.

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.28 pthread_key_delete

    Function Prototype: 

        #include <pthread.h>
    int pthread_key_delete(pthread_key_t key)

    Description:

    This POSIX function deletes a thread-specific data key previously returned by pthread_key_create(). No cleanup actions are done for data structures related to the deleted key or associated thread-specific data in any threads. It is undefined behavior to use key after it has been deleted.

    Input Parameters:

    Returned Value:

    If successful, the pthread_key_delete() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.29 pthread_mutexattr_init

    Function Prototype: 

        #include <pthread.h>
    int pthread_mutexattr_init(pthread_mutexattr_t *attr);

    Description:

    Input Parameters:

    Returned Value:

    If successful, the pthread_mutexattr_init() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.30 pthread_mutexattr_destroy

    Function Prototype: 

        #include <pthread.h>
    int pthread_mutexattr_destroy(pthread_mutexattr_t *attr);

    Description:

    Input Parameters:

    Returned Value:

    If successful, the pthread_mutexattr_destroy() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.31 pthread_mutexattr_getpshared

    Function Prototype: 

        #include <pthread.h>
    int pthread_mutexattr_getpshared(pthread_mutexattr_t *attr,
                                     int *pshared);

    Description:

    Input Parameters:

    Returned Value:

    If successful, the pthread_mutexattr_getpshared() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.32 pthread_mutexattr_setpshared

    Function Prototype: 

        #include <pthread.h>
   int pthread_mutexattr_setpshared(pthread_mutexattr_t *attr,
                                    int pshared);

    Description:

    Input Parameters:

    Returned Value:

    If successful, the pthread_mutexattr_setpshared() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.33 pthread_mutexattr_gettype

    Function Prototype: 

        #include <pthread.h>
#ifdef CONFIG_PTHREAD_MUTEX_TYPES
    int pthread_mutexattr_gettype(FAR const pthread_mutexattr_t *attr, FAR int *type);
#endif

    Description: Return the mutex type from the mutex attributes.

    Input Parameters:

    Returned Value:

    If successful, the pthread_mutexattr_settype() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.34 pthread_mutexattr_settype

    Function Prototype: 

        #include <pthread.h>
#ifdef CONFIG_PTHREAD_MUTEX_TYPES
    int pthread_mutexattr_settype(pthread_mutexattr_t *attr, int type);
#endif

    Description: Set the mutex type in the mutex attributes.

    Input Parameters:

    Returned Value:

    If successful, the pthread_mutexattr_settype() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.35 pthread_mutexattr_getprotocol

    Function Prototype: 

        #include <pthread.h>
    int pthread_mutexattr_getprotocol(FAR const pthread_mutexattr_t *attr,
                                      FAR int *protocol);

    Description: Return the value of the mutex protocol attribute..

    Input Parameters:

    Returned Value:

    If successful, the pthread_mutexattr_getprotocol() function will return zero (OK). Otherwise, an error number will be returned to indicate the error.

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.36 pthread_mutexattr_setprotocol

    Function Prototype: 

        #include <pthread.h>
    int pthread_mutexattr_setprotocol(FAR pthread_mutexattr_t *attr,
                                      int protocol);

    Description: Set mutex protocol attribute. See the paragraph Locking versus Signaling Semaphores for some important information about the use of this interface.

    Input Parameters:

    Returned Value:

    If successful, the pthread_mutexattr_setprotocol() function will return zero (OK). Otherwise, an error number will be returned to indicate the error.

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.37 pthread_mutex_init

    Function Prototype: 

        #include <pthread.h>
    int pthread_mutex_init(pthread_mutex_t *mutex,
                           pthread_mutexattr_t *attr);

    Description:

    Input Parameters:

    Returned Value:

    If successful, the pthread_mutex_init() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.38 pthread_mutex_destroy

    Function Prototype: 

        #include <pthread.h>
    int pthread_mutex_destroy(pthread_mutex_t *mutex);

    Description:

    Input Parameters:

    Returned Value:

    If successful, the pthread_mutex_destroy() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.39 pthread_mutex_lock

    Function Prototype: 

        #include <pthread.h>
    int pthread_mutex_lock(pthread_mutex_t *mutex);

    Description: The mutex object referenced by mutex is locked by calling pthread_mutex_lock(). If the mutex is already locked, the calling thread blocks until the mutex becomes available. This operation returns with the mutex object referenced by mutex in the locked state with the calling thread as its owner.

    If the mutex type is PTHREAD_MUTEX_NORMAL, deadlock detection is not provided. Attempting to re-lock the mutex causes deadlock. If a thread attempts to unlock a mutex that it has not locked or a mutex which is unlocked, undefined behavior results.

    In NuttX, PTHREAD_MUTEX_NORMAL is not implemented. Rather, the behavior described for PTHREAD_MUTEX_ERRORCHECK is the normal behavior.

    If the mutex type is PTHREAD_MUTEX_ERRORCHECK, then error checking is provided. If a thread attempts to re-lock a mutex that it has already locked, an error will be returned. If a thread attempts to unlock a mutex that it has not locked or a mutex which is unlocked, an error will be returned.

    If the mutex type is PTHREAD_MUTEX_RECURSIVE, then the mutex maintains the concept of a lock count. When a thread successfully acquires a mutex for the first time, the lock count is set to one. Every time a thread re-locks this mutex, the lock count is incremented by one. Each time the thread unlocks the mutex, the lock count is decremented by one. When the lock count reaches zero, the mutex becomes available for other threads to acquire. If a thread attempts to unlock a mutex that it has not locked or a mutex which is unlocked, an error will be returned.

    If a signal is delivered to a thread waiting for a mutex, upon return from the signal handler the thread resumes waiting for the mutex as if it was not interrupted.

    Input Parameters:

    Returned Value:

    If successful, the pthread_mutex_lock() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Note that this function will never return the error EINTR.

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.40 pthread_mutex_timedlock

    Function Prototype: 

        #include <pthread.h>
    int pthread_mutex_timedlock(pthread_mutex_t *mutex, const struct timespec *abs_timeout);

    Description: The pthread_mutex_timedlock() function will lock the mutex object referenced by mutex. If the mutex is already locked, the calling thread will block until the mutex becomes available as in the pthread_mutex_lock() function. If the mutex cannot be locked without waiting for another thread to unlock the mutex, this wait will be terminated when the specified abs_timeout expires.

    The timeout will expire when the absolute time specified by abs_timeout passes, as measured by the clock on which timeouts are based (that is, when the value of that clock equals or exceeds abs_timeout), or if the absolute time specified by abs_timeout has already been passed at the time of the call.

    Input Parameters:

    Returned Value:

    If successful, the pthread_mutex_trylock() function will return zero (OK). Otherwise, an error number will be returned to indicate the error. Note that the errno EINTR is never returned by pthread_mutex_timedlock(). The returned errno is ETIMEDOUT if the mutex could not be locked before the specified timeout expired

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name. This implementation does not return EAGAIN when the mutex could not be acquired because the maximum number of recursive locks for mutex has been exceeded.

    2.8.41 pthread_mutex_trylock

    Function Prototype: 

        #include <pthread.h>
    int pthread_mutex_trylock(pthread_mutex_t *mutex);

    Description: The function pthread_mutex_trylock() is identical to pthread_mutex_lock() except that if the mutex object referenced by mutex is currently locked (by any thread, including the current thread), the call returns immediately with the errno EBUSY.

    If a signal is delivered to a thread waiting for a mutex, upon return from the signal handler the thread resumes waiting for the mutex as if it was not interrupted.

    Input Parameters:

    Returned Value:

    If successful, the pthread_mutex_trylock() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Note that this function will never return the error EINTR.

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.42 pthread_mutex_unlock

    Function Prototype: 

        #include <pthread.h>
    int pthread_mutex_unlock(pthread_mutex_t *mutex);

    Description:

    The pthread_mutex_unlock() function releases the mutex object referenced by mutex. The manner in which a mutex is released is dependent upon the mutex's type attribute. If there are threads blocked on the mutex object referenced by mutex when pthread_mutex_unlock() is called, resulting in the mutex becoming available, the scheduling policy is used to determine which thread will acquire the mutex. (In the case of PTHREAD_MUTEX_RECURSIVE mutexes, the mutex becomes available when the count reaches zero and the calling thread no longer has any locks on this mutex).

    If a signal is delivered to a thread waiting for a mutex, upon return from the signal handler the thread resumes waiting for the mutex as if it was not interrupted.

    Input Parameters:

    Returned Value:

    If successful, the pthread_mutex_unlock() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Note that this function will never return the error EINTR.

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.42 pthread_condattr_init

    Function Prototype: 

        #include <pthread.h>
    int pthread_condattr_init(pthread_condattr_t *attr);

    Description:

    Input Parameters:

    Returned Value:

    If successful, the pthread_condattr_init() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.43 pthread_condattr_destroy

    Function Prototype: 

        #include <pthread.h>
    int pthread_condattr_destroy(pthread_condattr_t *attr);

    Description:

    Input Parameters:

    Returned Value:

    If successful, the pthread_condattr_destroy() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.44 pthread_cond_init

    Function Prototype: 

        #include <pthread.h>
    int pthread_cond_init(pthread_cond_t *cond, pthread_condattr_t *attr);

    Description:

    Input Parameters:

    Returned Value:

    If successful, the pthread_cond_init() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.45 pthread_cond_destroy

    Function Prototype: 

        #include <pthread.h>
    int pthread_cond_destroy(pthread_cond_t *cond);

    Description:

    Input Parameters:

    Returned Value:

    If successful, the pthread_cond_destroy() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.46 pthread_cond_broadcast

    Function Prototype: 

        #include <pthread.h>
    int pthread_cond_broadcast(pthread_cond_t *cond);

    Description:

    Input Parameters:

    Returned Value:

    If successful, the pthread_cond_broadcast() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.47 pthread_cond_signal

    Function Prototype: 

        #include <pthread.h>
    int pthread_cond_signal(pthread_cond_t *dond);

    Description:

    Input Parameters:

    Returned Value:

    If successful, the pthread_cond_signal() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.48 pthread_cond_wait

    Function Prototype: 

        #include <pthread.h>
    int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex);

    Description:

    Input Parameters:

    Returned Value:

    If successful, the pthread_cond_wait() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.49 pthread_cond_timedwait

    Function Prototype: 

        #include <pthread.h>
    int pthread_cond_timedwait(pthread_cond_t *cond, pthread_mutex_t *mutex,
                               const struct timespec *abstime);

    Description:

    Input Parameters:

    Returned Value:

    If successful, the pthread_cond_timedwait() function will return zero (OK). Otherwise, an error number will be returned to indicate the error:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.50 pthread_barrierattr_init

    Function Prototype: 

        #include <pthread.h>
    int pthread_barrierattr_init(FAR pthread_barrierattr_t *attr);

    Description: The pthread_barrierattr_init() function will initialize a barrier attribute object attr with the default value for all of the attributes defined by the implementation.

    Input Parameters:

    Returned Value: 0 (OK) on success or EINVAL if attr is invalid.

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.51 pthread_barrierattr_destroy

    Function Prototype: 

        #include <pthread.h>
    int pthread_barrierattr_destroy(FAR pthread_barrierattr_t *attr);

    Description: The pthread_barrierattr_destroy() function will destroy a barrier attributes object. A destroyed attributes object can be reinitialized using pthread_barrierattr_init(); the results of otherwise referencing the object after it has been destroyed are undefined.

    Input Parameters:

    Returned Value: 0 (OK) on success or EINVAL if attr is invalid.

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.52 pthread_barrierattr_setpshared

    Function Prototype: 

        #include <pthread.h>
    int pthread_barrierattr_setpshared(FAR pthread_barrierattr_t *attr, int pshared);

    Description: The process-shared attribute is set to PTHREAD_PROCESS_SHARED to permit a barrier to be operated upon by any thread that has access to the memory where the barrier is allocated. If the process-shared attribute is PTHREAD_PROCESS_PRIVATE, the barrier can only be operated upon by threads created within the same process as the thread that initialized the barrier. If threads of different processes attempt to operate on such a barrier, the behavior is undefined. The default value of the attribute is PTHREAD_PROCESS_PRIVATE.

    Input Parameters:

    Returned Value: 0 (OK) on success or EINVAL if either attr is invalid or pshared is not one of PTHREAD_PROCESS_SHARED or PTHREAD_PROCESS_PRIVATE.

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.53 pthread_barrierattr_getpshared

    Function Prototype: 

        #include <pthread.h>
    int pthread_barrierattr_getpshared(FAR const pthread_barrierattr_t *attr, FAR int *pshared);

    Description: The pthread_barrierattr_getpshared() function will obtain the value of the process-shared attribute from the attributes object referenced by attr.

    Input Parameters:

    Returned Value: 0 (OK) on success or EINVAL if either attr or pshared is invalid.

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.54 pthread_barrier_init

    Function Prototype: 

        #include <pthread.h>
    int pthread_barrier_init(FAR pthread_barrier_t *barrier,
                             FAR const pthread_barrierattr_t *attr, unsigned int count);

    Description: The pthread_barrier_init() function allocates any resources required to use the barrier referenced by barrier and initialized the barrier with the attributes referenced by attr. If attr is NULL, the default barrier attributes will be used. The results are undefined if pthread_barrier_init() is called when any thread is blocked on the barrier. The results are undefined if a barrier is used without first being initialized. The results are undefined if pthread_barrier_init() is called specifying an already initialized barrier.

    Input Parameters:

    Returned Value: 0 (OK) on success or one of the following error numbers:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.55 pthread_barrier_destroy

    Function Prototype: 

        #include <pthread.h>
    int pthread_barrier_destroy(FAR pthread_barrier_t *barrier);

    Description: The pthread_barrier_destroy() function destroys the barrier referenced by barrie and releases any resources used by the barrier. The effect of subsequent use of the barrier is undefined until the barrier is reinitialized by another call to pthread_barrier_init(). The results are undefined if pthread_barrier_destroy() is called when any thread is blocked on the barrier, or if this function is called with an uninitialized barrier.

    Input Parameters:

    Returned Value: 0 (OK) on success or one of the following error numbers:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.56 pthread_barrier_wait

    Function Prototype: 

        #include <pthread.h>
    int pthread_barrier_wait(FAR pthread_barrier_t *barrier);

    Description: The pthread_barrier_wait() function synchronizes participating threads at the barrier referenced by barrier. The calling thread is blocked until the required number of threads have called pthread_barrier_wait() specifying the same barrier. When the required number of threads have called pthread_barrier_wait() specifying the barrier, the constant PTHREAD_BARRIER_SERIAL_THREAD will be returned to one unspecified thread and zero will be returned to each of the remaining threads. At this point, the barrier will be reset to the state it had as a result of the most recent pthread_barrier_init() function that referenced it.

    The constant PTHREAD_BARRIER_SERIAL_THREAD is defined in pthread.h and its value must be distinct from any other value returned by pthread_barrier_wait().

    The results are undefined if this function is called with an uninitialized barrier.

    If a signal is delivered to a thread blocked on a barrier, upon return from the signal handler the thread will resume waiting at the barrier if the barrier wait has not completed. Otherwise, the thread will continue as normal from the completed barrier wait. Until the thread in the signal handler returns from it, it is unspecified whether other threads may proceed past the barrier once they have all reached it.

    A thread that has blocked on a barrier will not prevent any unblocked thread that is eligible to use the same processing resources from eventually making forward progress in its execution. Eligibility for processing resources will be determined by the scheduling policy.

    Input Parameters:

    Returned Value: 0 (OK) on success or EINVAL if the barrier is not valid.

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.57 pthread_once

    Function Prototype: 

        #include <pthread.h>
    int pthread_once(FAR pthread_once_t *once_control, CODE void (*init_routine)(void));

    Description: The first call to pthread_once() by any thread with a given once_control, will call the init_routine() with no arguments. Subsequent calls to pthread_once() with the same once_control will have no effect. On return from pthread_once(), init_routine() will have completed.

    Input Parameters:

    Returned Value: 0 (OK) on success or EINVAL if either once_control or init_routine are invalid.

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.58 pthread_kill

    Function Prototype: 

        #include <signal.h>
    #include <pthread.h>
    int pthread_kill(pthread_t thread, int signo)

    Description: The pthread_kill() system call can be used to send any signal to a thread. See kill() for further information as this is just a simple wrapper around the kill() function.

    Input Parameters:

    Returned Value:

    On success, the signal was sent and zero is returned. On error one of the following error numbers is returned.

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.8.59 pthread_sigmask

    Function Prototype: 

        #include <signal.h>
    #include <pthread.h>
    int pthread_sigmask(int how, FAR const sigset_t *set, FAR sigset_t *oset);

    Description: This function is a simple wrapper around sigprocmask(). See the sigprocmask() function description for further information.

    Input Parameters:

    Returned Value:

    Assumptions/Limitations:

    POSIX Compatibility: Comparable to the POSIX interface of the same name.

    2.9 Environment Variables

    Overview. NuttX supports environment variables that can be used to control the behavior of programs. In the spirit of NuttX the environment variable behavior attempts to emulate the behavior of environment variables in the multi-processing OS:

    Programming Interfaces. The following environment variable programming interfaces are provided by Nuttx and are described in detail in the following paragraphs.

    Disabling Environment Variable Support. All support for environment variables can be disabled by setting CONFIG_DISABLE_ENVIRON in the board configuration file.

    2.9.1 getenv

    Function Prototype: 

      #include <stdlib.h>
  FAR char *getenv(const char *name);

    Description: The getenv() function searches the environment list for a string that matches the string pointed to by name.

    Input Parameters:

    Returned Value: The value of the variable (read-only) or NULL on failure.

    2.9.2 putenv

    Function Prototype: 

      #include <stdlib.h>
  int putenv(char *string);

    Description: The putenv() function adds or changes the value of environment variables. The argument string is of the form name=value. If name does not already exist in the environment, then string is added to the environment. If name does exist, then the value of name in the environment is changed to value.

    Input Parameters:

    Returned Value: Zero on success.

    2.9.3 clearenv

    Function Prototype: 

      #include <stdlib.h>
  int clearenv(void);

    Description: The clearenv() function clears the environment of all name-value pairs and sets the value of the external variable environ to NULL.

    Input Parameters: None

    Returned Value: Zero on success.

    2.9.4 setenv

    Function Prototype: 

      #include <stdlib.h>
  int setenv(const char *name, const char *value, int overwrite);

    Description: The setenv() function adds the variable name to the environment with the specified value if the variable name does not exist. If the name does exist in the environment, then its value is changed to value if overwrite is non-zero; if overwrite is zero, then the value of name is unaltered.

    Input Parameters:

    Returned Value: Zero on success.

    2.9.5 unsetenv

    Function Prototype: 

      #include <stdlib.h>
  int unsetenv(const char *name);

    Description: The unsetenv() function deletes the variable name from the environment.

    Input Parameters:

    Returned Value: Zero on success.

    2.10 File System Interfaces

    2.10.1 NuttX File System Overview

    Overview. NuttX includes an optional, scalable file system. This file-system may be omitted altogether; NuttX does not depend on the presence of any file system.

    Pseudo Root File System. A simple in-memory, pseudo file system can be enabled by default. This is an in-memory file system because it does not require any storage medium or block driver support. Rather, file system contents are generated on-the-fly as referenced via standard file system operations (open, close, read, write, etc.). In this sense, the file system is pseudo file system (in the same sense that the Linux /proc file system is also referred to as a pseudo file system).

    Any user supplied data or logic can be accessed via the pseudo-file system. Built in support is provided for character and block driver nodes in the any pseudo file system directory. (By convention, however, all driver nodes should be in the /dev pseudo file system directory).

    Mounted File Systems The simple in-memory file system can be extended my mounting block devices that provide access to true file systems backed up via some mass storage device. NuttX supports the standard mount() command that allows a block driver to be bound to a mount-point within the pseudo file system and to a a file system. At present, NuttX supports only the VFAT file system.

    Comparison to Linux From a programming perspective, the NuttX file system appears very similar to a Linux file system. However, there is a fundamental difference: The NuttX root file system is a pseudo file system and true file systems may be mounted in the pseudo file system. In the typical Linux installation by comparison, the Linux root file system is a true file system and pseudo file systems may be mounted in the true, root file system. The approach selected by NuttX is intended to support greater scalability from the very tiny platform to the moderate platform.

    File System Interfaces. The NuttX file system simply supports a set of standard, file system APIs (open(), close(), read(), write, etc.) and a registration mechanism that allows devices drivers to a associated with nodes in a file-system-like name space.

    2.10.2 Driver Operations

    2.10.2.1 fcntl.h

    2.10.2.2 unistd.h

    2.10.2.3 sys/ioctl.h

    2.10.2.4 poll.h

    2.10.2.4.1 poll

    Function Prototype: 

      #include <poll.h>
  int poll(struct pollfd *fds, nfds_t nfds, int timeout);

    Description: poll() waits for one of a set of file descriptors to become ready to perform I/O. If none of the events requested (and no error) has occurred for any of the file descriptors, then poll() blocks until one of the events occurs.

    Configuration Settings. In order to use the select with TCP/IP sockets test, you must have the following things selected in your NuttX configuration file:

    In order to for select to work with incoming connections, you must also select:

    Input Parameters:

    Returned Value:

    On success, the number of structures that have nonzero revents fields. A value of 0 indicates that the call timed out and no file descriptors were ready. On error, -1 is returned, and errno is set appropriately:

    2.10.2.5 sys/select.h

    2.10.2.5.1 select

    Function Prototype:

    Description: select() allows a program to monitor multiple file descriptors, waiting until one or more of the file descriptors become "ready" for some class of I/O operation (e.g., input possible). A file descriptor is considered ready if it is possible to perform the corresponding I/O operation (e.g., read(2)) without blocking.

    NOTE: poll() is the fundamental API for performing such monitoring operation under NuttX. select() is provided for compatibility and is simply a layer of added logic on top of poll(). As such, select() is more wasteful of resources and poll() is the recommended API to be used.

    Input Parameters:

    Returned Value:

    2.10.3 Directory Operations

    2.10.4 UNIX Standard Operations

    2.10.5 Standard I/O

    2.10.6 Standard Library

    stdlib.h generally addresses other operating system interfaces. However, the following may also be considered as file system interfaces:

    2.10.7 Asynchronous I/O

    2.10.8 Standard String Operations

    2.10.9 Pipes and FIFOs

    2.10.9.1 pipe

    Function Prototype:

    Description:

    Input Parameters:

    Returned Value:

    2.10.9.2 mkfifo

    Function Prototype:

    Description:

    Input Parameters:

    Returned Value:

    2.10.10 mmap() and eXecute In Place (XIP)

    NuttX operates in a flat open address space and is focused on MCUs that do support Memory Management Units (MMUs). Therefore, NuttX generally does not require mmap() functionality and the MCUs generally cannot support true memory-mapped files.

    However, memory mapping of files is the mechanism used by NXFLAT, the NuttX tiny binary format, to get files into memory in order to execute them. mmap() support is therefore required to support NXFLAT. There are two conditions where mmap() can be supported:

    1. mmap() can be used to support eXecute In Place (XIP) on random access media under the following very restrictive conditions:

      1. The file-system supports the FIOC_MMAP ioctl command. Any file system that maps files contiguously on the media should support this ioctl command. By comparison, most file system scatter files over the media in non-contiguous sectors. As of this writing, ROMFS is the only file system that meets this requirement.

      2. The underlying block driver supports the BIOC_XIPBASE ioctl command that maps the underlying media to a randomly accessible address. At present, only the RAM/ROM disk driver does this.

      Some limitations of this approach are as follows:

      1. Since no real mapping occurs, all of the file contents are "mapped" into memory.

      2. All mapped files are read-only.

      3. There are no access privileges.

    2. If CONFIG_FS_RAMMAP is defined in the configuration, then mmap() will support simulation of memory mapped files by copying files whole into RAM. These copied files have some of the properties of standard memory mapped files. There are many, many exceptions exceptions, however. Some of these include:

      1. The goal is to have a single region of memory that represents a single file and can be shared by many threads. That is, given a filename a thread should be able to open the file, get a file descriptor, and call mmap() to get a memory region. Different file descriptors opened with the same file path should get the same memory region when mapped.

        The limitation in the current design is that there is insufficient knowledge to know that these different file descriptors correspond to the same file. So, for the time being, a new memory region is created each time that rammmap() is called. Not very useful!

      2. The entire mapped portion of the file must be present in memory. Since it is assumed that the MCU does not have an MMU, on-demanding paging in of file blocks cannot be supported. Since the while mapped portion of the file must be present in memory, there are limitations in the size of files that may be memory mapped (especially on MCUs with no significant RAM resources).

      3. All mapped files are read-only. You can write to the in-memory image, but the file contents will not change.

      4. There are no access privileges.

      5. Since there are no processes in NuttX, all mmap() and munmap() operations have immediate, global effects. Under Linux, for example, munmap() would eliminate only the mapping with a process; the mappings to the same file in other processes would not be effected.

      6. Like true mapped file, the region will persist after closing the file descriptor. However, at present, these ram copied file regions are not automatically "unmapped" (i.e., freed) when a thread is terminated. This is primarily because it is not possible to know how many users of the mapped region there are and, therefore, when would be the appropriate time to free the region (other than when munmap is called).

        NOTE: Note, if the design limitation of a) were solved, then it would be easy to solve exception d) as well.

    2.10.11.1 mmap

    Function Prototype:

    Description:

    Input Parameters:

    Returned Value:

    2.11 Network Interfaces

    NuttX supports a BSD-compatible socket interface layer. These socket interface can be enabled by settings in the architecture configuration file. Those socket APIs are discussed in the following paragraphs.

    2.11.1 socket

    Function Prototype:

    Description: socket() creates an endpoint for communication and returns a descriptor.

    Input Parameters:

    Returned Value: 0 on success; -1 on error with errno set appropriately:

    2.11.2 bind

    Function Prototype:

    Description: bind() gives the socket sockfd the local address addr. addr is addrlen bytes long. Traditionally, this is called "assigning a name to a socket." When a socket is created with socket(), it exists in a name space (address family) but has no name assigned.

    Input Parameters:

    Returned Value: 0 on success; -1 on error with errno set appropriately:

    2.11.3 connect

    Function Prototype:

    Description: connect() connects the socket referred to by the file descriptor sockfd to the address specified by addr. The addrlen argument specifies the size of addr. The format of the address in addr is determined by the address space of the socket sockfd. If the socket sockfd is of type SOCK_DGRAM then addr is the address to which datagrams are sent by default, and the only address from which datagrams are received. If the socket is of type SOCK_STREAM or SOCK_SEQPACKET, this call attempts to make a connection to the socket that is bound to the address specified by addr. Generally, connection-based protocol sockets may successfully connect() only once; connectionless protocol sockets may use connect() multiple times to change their association. Connectionless sockets may dissolve the association by connecting to an address with the sa_family member of sockaddr set to AF_UNSPEC.

    Input Parameters:

    Returned Value: 0 on success; -1 on error with errno set appropriately:

  • EACCES or EPERM: The user tried to connect to a broadcast address without having the socket broadcast flag enabled or the connection request failed because of a local firewall rule.
  • EADDRINUSE Local address is already in use.
  • EAFNOSUPPORT The passed address didn't have the correct address family in its sa_family field.
  • EAGAIN No more free local ports or insufficient entries in the routing cache. For PF_INET.
  • EALREADY The socket is non-blocking and a previous connection attempt has not yet been completed.
  • EBADF The file descriptor is not a valid index in the descriptor table.
  • ECONNREFUSED No one listening on the remote address.
  • EFAULT The socket structure address is outside the user's address space.
  • EINPROGRESS The socket is non-blocking and the connection cannot be completed immediately.
  • EINTR The system call was interrupted by a signal that was caught.
  • EISCONN The socket is already connected.
  • ENETUNREACH Network is unreachable.
  • ENOTSOCK The file descriptor is not associated with a socket.
  • ETIMEDOUT Timeout while attempting connection. The server may be too busy to accept new connections.

    • 2.11.4 listen

    Function Prototype:

    Description: To accept connections, a socket is first created with socket(), a willingness to accept incoming connections and a queue limit for incoming connections are specified with listen(), and then the connections are accepted with accept(). The listen() call applies only to sockets of type SOCK_STREAM or SOCK_SEQPACKET.

    Input Parameters:

    Returned Value: On success, zero is returned. On error, -1 is returned, and errno is set appropriately.

    2.11.5 accept

    Function Prototype:

    Description: The accept() function is used with connection-based socket types (SOCK_STREAM, SOCK_SEQPACKET and SOCK_RDM). It extracts the first connection request on the queue of pending connections, creates a new connected socket with most of the same properties as sockfd, and allocates a new socket descriptor for the socket, which is returned. The newly created socket is no longer in the listening state. The original socket sockfd is unaffected by this call. Per file descriptor flags are not inherited across an accept.

    The sockfd argument is a socket descriptor that has been created with socket(), bound to a local address with bind(), and is listening for connections after a call to listen().

    On return, the addr structure is filled in with the address of the connecting entity. The addrlen argument initially contains the size of the structure pointed to by addr; on return it will contain the actual length of the address returned.

    If no pending connections are present on the queue, and the socket is not marked as non-blocking, accept blocks the caller until a connection is present. If the socket is marked non-blocking and no pending connections are present on the queue, accept returns EAGAIN.

    Input Parameters:

    Returned Value: Returns -1 on error. If it succeeds, it returns a non-negative integer that is a descriptor for the accepted socket.

    2.11.6 send

    Function Prototype:

    Description: The send() call may be used only when the socket is in a connected state (so that the intended recipient is known). The only difference between send() and write() is the presence of flags. With zero flags parameter, send() is equivalent to write(). Also, send(s,buf,len,flags) is equivalent to sendto(s,buf,len,flags,NULL,0).

    Input Parameters:

    Returned Value: See sendto().

    2.11.7 sendto

    Function Prototype:

    Description: If sendto() is used on a connection-mode (SOCK_STREAM, SOCK_SEQPACKET) socket, the parameters to and tolen are ignored (and the error EISCONN may be returned when they are not NULL and 0), and the error ENOTCONN is returned when the socket was not actually connected.

    Input Parameters:

    Returned Value: On success, returns the number of characters sent. On error, -1 is returned, and errno is set appropriately:

    2.11.8 recv

    Function Prototype:

    Description: The recv() call is identical to recvfrom() with a NULL from parameter.

    Input Parameters:

    Returned Value: See recvfrom().

    2.11.9 recvfrom

    Function Prototype:

    Description: recvfrom() receives messages from a socket, and may be used to receive data on a socket whether or not it is connection-oriented.

    If from is not NULL, and the underlying protocol provides the source address, this source address is filled in. The argument fromlen initialized to the size of the buffer associated with from, and modified on return to indicate the actual size of the address stored there.

    Input Parameters:

    Returned Value: On success, returns the number of characters sent. If no data is available to be received and the peer has performed an orderly shutdown, recv() will return 0. Otherwise, on errors, -1 is returned, and errno is set appropriately:

    2.11.10 setsockopt

    Function Prototype:

    Description: setsockopt() sets the option specified by the option argument, at the protocol level specified by the level argument, to the value pointed to by the value argument for the socket associated with the file descriptor specified by the sockfd argument.

    The level argument specifies the protocol level of the option. To set options at the socket level, specify the level argument as SOL_SOCKET.

    See sys/socket.h for a complete list of values for the option argument.

    Input Parameters:

    Returned Value: On success, returns the number of characters sent. On error, -1 is returned, and errno is set appropriately:

    2.11.11 getsockopt

    Function Prototype:

    Description: getsockopt() retrieve those value for the option specified by the option argument for the socket specified by the sockfd argument. If the size of the option value is greater than value_len, the value stored in the object pointed to by the value argument will be silently truncated. Otherwise, the length pointed to by the value_len argument will be modified to indicate the actual length of the value.

    The level argument specifies the protocol level of the option. To retrieve options at the socket level, specify the level argument as SOL_SOCKET.

    See sys/socket.h for a complete list of values for the option argument.

    Input Parameters:

    Returned Value: On success, returns the number of characters sent. On error, -1 is returned, and errno is set appropriately:

    2.12 Shared Memory Interfaces

    Shared memory interfaces are only available with the NuttX kernel build (CONFIG_BUILD_KERNEL=y). These interfaces support user memory regions that can be shared between multiple user processes. Shared memory interfaces:

    2.12.1 shmget

    Function Prototype:

    Description: The shmget() function will return the shared memory identifier associated with key.

    A shared memory identifier, associated data structure, and shared memory segment of at least size bytes is created for key if one of the following is true:

    Upon creation, the data structure associated with the new shared memory identifier will be initialized as follows:

    When the shared memory segment is created, it will be initialized with all zero values.

    Input Parameters:

    Returned Value: Upon successful completion, shmget() will return a non-negative integer, namely a shared memory identifier; otherwise, it will return -1 and set errno to indicate the error.

    POSIX Deviations

    2.12.2 shmat

    Function Prototype:

    Description: The shmat() function attaches the shared memory segment associated with the shared memory identifier specified by shmid to the address space of the calling process. The segment is attached at the address specified by one of the following criteria:

    Input Parameters:

    Returned Value: Upon successful completion, shmat() will increment the value of shm_nattch in the data structure associated with the shared memory ID of the attached shared memory segment and return the segment's start address. Otherwise, the shared memory segment will not be attached, shmat() will return -1, and errno will be set to indicate the error.

    2.12.3 shmctl

    Function Prototype:

    Description: The shmctl() function provides a variety of shared memory control operations as specified by cmd. The following values for cmd are available:

    Input Parameters:

    Returned Value: Upon successful completion, shmctl() will return 0; otherwise, it will return -1 and set errno to indicate the error.

    POSIX Deviations

    2.12.4 shmdt

    Function Prototype:

    Description: The shmdt() function detaches the shared memory segment located at the address specified by shmaddr from the address space of the calling process.

    Input Parameters:

    Returned Value: Upon successful completion, shmdt() will decrement the value of shm_nattch in the data structure associated with the shared memory ID of the attached shared memory segment and return 0.

    Otherwise, the shared memory segment will not be detached, shmdt() will return -1, and errno will be set to indicate the error.

    3.0 OS Data Structures

    3.1 Scalar Types

    Many of the types used to communicate with NuttX are simple scalar types. These types are used to provide architecture independence of the OS from the application. The scalar types used at the NuttX interface include:

    3.2 Hidden Interface Structures

    Several of the types used to interface with NuttX are structures that are intended to be hidden from the application. From the standpoint of the application, these structures (and structure pointers) should be treated as simple handles to reference OS resources. These hidden structures include:

    In order to maintain portability, applications should not reference specific elements within these hidden structures. These hidden structures will not be described further in this user's manual.

    3.3 Access to the errno Variable

    A pointer to the thread-specific errno value is available through a function call:

    Function Prototype:

    Description: __errno() returns a pointer to the thread-specific errno value. Note that the symbol errno is defined to be __errno() so that the usual access by referencing the symbol errno will work as expected.

    There is a unique, private errno value for each NuttX task. However, the implementation of errno differs somewhat from the use of errno in most multi-threaded process environments: In NuttX, each pthread will also have its own private copy of errno and the errno will not be shared between pthreads. This is, perhaps, non-standard but promotes better thread independence.

    Input Parameters: None

    Returned Values:

    3.4 User Interface Structures

    3.4.1 main_t

    main_t defines the type of a task entry point. main_t is declared in sys/types.h as: 

        typedef int (*main_t)(int argc, char *argv[]);

    3.4.2 struct sched_param

    This structure is used to pass scheduling priorities to and from NuttX; 

        struct sched_param
    {
      int sched_priority;
    };

    3.4.3 struct timespec

    This structure is used to pass timing information between the NuttX and a user application: 

        struct timespec
    {
      time_t tv_sec;  /* Seconds */
      long   tv_nsec; /* Nanoseconds */
    };

    3.4.4 struct mq_attr

    This structure is used to communicate message queue attributes between NuttX and a MoBY application: 

        struct mq_attr {
      size_t       mq_maxmsg;   /* Max number of messages in queue */
      size_t       mq_msgsize;  /* Max message size */
      unsigned     mq_flags;    /* Queue flags */
      size_t       mq_curmsgs;  /* Number of messages currently in queue */
    };

    3.4.5 struct sigaction

    The following structure defines the action to take for given signal: 

        struct sigaction
    {
      union
      {
        void (*_sa_handler)(int);
        void (*_sa_sigaction)(int, siginfo_t *, void *);
      } sa_u;
      sigset_t           sa_mask;
      int                sa_flags;
    };
    #define sa_handler   sa_u._sa_handler
    #define sa_sigaction sa_u._sa_sigaction

    3.4.6 struct siginfo/siginfo_t

    The following types is used to pass parameters to/from signal handlers: 

        typedef struct siginfo
    {
      int          si_signo;
      int          si_code;
      union sigval si_value;
   } siginfo_t;

    3.4.7 union sigval

    This defines the type of the struct siginfo si_value field and is used to pass parameters with signals. 

        union sigval
    {
      int   sival_int;
      void *sival_ptr;
    };

    3.4.8 struct sigevent

    The following is used to attach a signal to a message queue to notify a task when a message is available on a queue. 

        struct sigevent
    {
      int          sigev_signo;
      union sigval sigev_value;
      int          sigev_notify;
    };

    Index
  • accept
  • aio.h
  • aio_cancel
  • aio_error
  • aio_fsync
  • aio_read
  • aio_return
  • aio_suspend
  • aio_write
  • asctime
  • asctime_r
  • atexit
  • bind
  • BIOC_XIPBASE
  • chdir
  • clock_getres
  • clock_gettime
  • Clocks
  • clock_settime
  • close
  • closedir
  • connect
  • creat
  • ctime
  • ctime_r
  • Data structures
  • Directory operations
  • dirent.h
  • Driver operations
  • dup
  • dup2
  • execl
  • eXecute In Place (XIP)
  • exec
  • execv
  • exit
  • FAT File System Support
  • fclose
  • fcntl
  • fcntl.h
  • fdopen
  • feof
  • ferror
  • File system, interfaces
  • File system, overview
  • fflush
  • fgetc
  • fgetpos
  • fgets
  • FIOC_MMAP
  • fopen
  • fprintf
  • fputc
  • fputs
  • fread
  • fseek
  • fsetpos
  • fstat
  • ftell
  • fwrite
  • getcwd
  • getpid
  • gets
  • getsockopt
  • gmtime
  • gmtime_r
  • Introduction
  • ioctl
  • kill
  • lio_listio
  • listen
  • localtime_r
  • Locking versus Signaling Semaphores
  • lseek
  • Named Message Queue Interfaces
  • mkdir
  • mkfifo
  • mktime
  • mq_close
  • mq_getattr
  • mq_notify
  • mq_open
  • mq_receive
  • mq_send
  • mq_setattr
  • mq_timedreceive
  • mq_timedsend
  • mq_unlink
  • mmap
  • Network Interfaces
    		•
  • on_exit
  • open
  • opendir
  • OS Interfaces
  • pause
  • pipe
  • poll
  • poll.h
  • posix_spawn
  • posix_spawn_file_actions_addclose
  • posix_spawn_file_actions_adddup2
  • posix_spawn_file_actions_addopen
  • posix_spawn_file_actions_destroy
  • posix_spawn_file_actions_init
  • posix_spawnattr_init
  • posix_spawnattr_destroy
  • posix_spawnattr_getflags
  • posix_spawnattr_getschedparam
  • posix_spawnattr_getschedpolicy
  • posix_spawnattr_getsigmask
  • posix_spawnattr_setflags
  • posix_spawnattr_setschedparam
  • posix_spawnattr_setschedpolicy
  • posix_spawnattr_setsigmask
  • posix_spawnp
  • pread
  • printf
  • pwrite
  • Pthread Interfaces
  • pthread_attr_destroy
  • pthread_attr_getinheritsched
  • pthread_attr_getschedparam
  • pthread_attr_getschedpolicy
  • pthread_attr_getstacksize
  • pthread_attr_init
  • pthread_attr_setinheritsched
  • pthread_attr_setschedparam
  • pthread_attr_setschedpolicy
  • pthread_attr_setstacksize
  • pthread_barrierattr_init
  • pthread_barrierattr_destroy
  • pthread_barrierattr_getpshared
  • pthread_barrierattr_setpshared
  • pthread_barrier_destroy
  • pthread_barrier_init
  • pthread_barrier_wait
  • pthread_cancel
  • pthread_condattr_init
  • pthread_cond_broadcast
  • pthread_cond_destroy
  • pthread_cond_init
  • pthread_cond_signal
  • pthread_cond_timedwait
  • pthread_cond_wait
  • pthread_create
  • pthread_detach
  • pthread_exit
  • pthread_getschedparam
  • pthread_getspecific
  • pthreads share some resources.
  • pthread_join
  • pthread_key_create
  • pthread_key_delete
  • pthread_kill
  • pthread_mutexattr_destroy
  • pthread_mutexattr_getprotocol
  • pthread_mutexattr_getpshared
  • pthread_mutexattr_gettype
  • pthread_mutexattr_init
  • pthread_mutexattr_setprotocol
  • pthread_mutexattr_setpshared
  • pthread_mutexattr_settype
  • pthread_mutex_destroy
  • pthread_mutex_init
  • pthread_mutex_lock
  • pthread_mutex_timedlock
  • pthread_mutex_trylock
  • pthread_mutex_unlock
  • pthread_condattr_destroy
  • pthread_once
  • pthread_self
  • pthread_setcancelstate
  • pthread_setcanceltype
  • pthread_setschedparam
  • pthread_setspecific
  • pthread_sigmask
  • pthread_testcancel
  • pthread_yield
  • puts
  • RAM disk driver
  • read
    		•
  • readdir
  • readdir_r
  • recv
  • recvfrom
  • rename
  • rmdir
  • rewinddir
  • ROM disk driver
  • ROMFS
  • sched_getparam
  • sched_get_priority_max
  • sched_get_priority_min
  • sched_get_rr_interval
  • sched_lockcount
  • sched_lock
  • sched_setparam
  • sched_setscheduler
  • sched_unlock
  • sched_yield
  • select
  • Counting Semaphore Interfaces
  • sem_close
  • sem_destroy
  • sem_getprotocol
  • sem_getvalue
  • sem_init
  • sem_open
  • sem_post
  • sem_setprotocol
  • sem_trywait
  • sem_unlink
  • sem_wait
  • sched_getscheduler
  • seekdir
  • send
  • sendto
  • setsockopt
  • sigaction
  • sigaddset
  • sigdelset
  • sigemptyset
  • sigfillset
  • sigismember
  • Signal Interfaces
  • sigpending
  • sigprocmask
  • sigqueue
  • sigsuspend
  • sigtimedwait
  • sigwaitinfo
  • socket
  • sprintf
  • Standard I/O
  • stat
  • statfs
  • stdio.h
  • sys/select.h
  • sys/ioctl.h
  • Task Control Interfaces
  • task_create
  • task_delete
  • task_restart
  • Task Scheduling Interfaces
  • task_setcancelstate
  • task_setcanceltype
  • task_spawn
  • task_spawnattr_getstacksize
  • task_spawnattr_setstacksize
  • Task Switching Interfaces
  • task_testcancel
  • telldir
  • timer_create
  • timer_delete
  • timer_getoverrun
  • timer_gettime
  • Timers
  • timer_settime
  • ungetc
  • unistd.h, unistd.h
  • unlink
  • vfork
  • vfprintf
  • vprintf
  • vsprintf
  • wait
  • waitid
  • waitpid
  • write
  • XIP
    		•