_lwp_create(2)

NAME | SYNOPSIS | DESCRIPTION | RETURN VALUES | ERRORS | EXAMPLES | SEE ALSO | NOTES

NAME

_lwp_create- create a new light-weight process

SYNOPSIS

#include <sys/lwp.h>

int _lwp_create(ucontext_t *contextp, unsigned long flags, lwpid_t *new_lwp);

DESCRIPTION

The _lwp_create() function adds a lightweight process (LWP) to the current process. The contextp argument specifies the initial signal mask, stack, and machine context (including the program counter and stack pointer) for the new LWP. The new LWP inherits the scheduling class and priority of the caller.

If _lwp_create() is successful and new_lwp is not null, the ID of the new LWP is stored in the location pointed to by new_lwp.

The flags argument specifies additional attributes for the new LWP. The value in flags is constructed by the bitwise inclusive OR operation of the following values:

LWP_DETACHED

The LWP is created detached.

LWP_SUSPENDED

The LWP is created suspended.

__LWP_ASLWP

The LWP created is the ASLWP (Asynchronous Signals LWP) (see signal(3HEAD)). The ASLWP should always be created with all signals blocked. If __LWP_ASLWP is specified, then the LWP created is the special, designated LWP that handles signals sent to a multithreaded process (ASLWP). There can be only one ASLWP in a multithreaded process, so the creation of another ASLWP will return EINVAL. It should never exit by way of _lwp_exit(2) or exit(2). This is a reserved flag and should not be used by any user program. It is documented here for the sake of completion and not for use by an application.

If LWP_DETACHED is specified, then the LWP is created in the detached state. Otherwise the LWP is created in the undetached state. The ID (and system resources) associated with a detached LWP can be automatically reclaimed when the LWP exits. The ID of an undetached LWP cannot be reclaimed until it exits and another LWP has reported its termination by way of _lwp_wait(2). This allows the waiting LWP to determine that the waited for LWP has terminated and to reclaim any process resources that it was using.

If LWP_SUSPENDED is specified, then the LWP is created in a suspended state. This allows the creator to change the LWP's inherited attributes before it starts to execute. The suspended LWP can only be resumed by way of _lwp_continue(2). If LWP_SUSPENDED is not specified the LWP can begin to run immediately after it has been created.

RETURN VALUES

Upon successful completion, 0 is returned. A non-zero value indicates an error.

ERRORS

If any of the following conditions are detected, _lwp_create() fails and returns the corresponding value:

EFAULT

Either the context parameter or the new_lwp parameter point to invalid addresses.

EAGAIN

A system limit is exceeded, (for example, too many LWP were created for this real user ID).

EINVAL

The __LWP_ASLWP flag was used to create more than one ASLWP in the process. There can be only one ASLWP within a process.

EXAMPLES

---

Example 1 How a stack is allocated to a new LWP.




This example shows how a stack is allocated to a new LWP. The _lwp_makecontext() function is used to set up the context parameter so that the new LWP begins executing a function.

contextp = (ucontext_t *)malloc(sizeof(ucontext_t));
stackbase = malloc(stacksize);
sigprocmask(SIGSETMASK, NULL, &contextp->uc_sigmask);
_lwp_makecontext(contextp, func, arg, private, stackbase, stacksize);
error = _lwp_create(contextp, NULL, &new_lwp);

---

SEE ALSO

_lwp_cond_timedwait(2), _lwp_continue(2), _lwp_exit(2), _lwp_makecontext(2), _lwp_wait(2), alarm(2), exit(2), poll(2), sleep(3C), thr_create(3THR), signal(3HEAD), ucontext(3HEAD)

NOTES

Applications should use bound threads rather than the _lwp_*( ) functions (see thr_create(3THR)). Using LWPs directly is not advised because libraries are only safe to use with threads, not LWPs.

In Solaris releases 2.5 through 7, the signal SIGALRM is defined to be per-process. This does not affect the behavior of single-threaded or multithreaded applications. If the application was using LWPs directly, and was relying on alarm(2) or sleep(3C), then the application's behavior might be impacted. The calling LWP will not necessarily be the recipient of the SIGARLM signal when SIGALRM is sent to the process. You might have to use a substitute like poll(2), or _lwp_cond_timedwait(2) to simulate the old per-LWP semantic of SIGALRM.

SunOS 5.8  Last Revised 28 Nov 1995

NAME | SYNOPSIS | DESCRIPTION | RETURN VALUES | ERRORS | EXAMPLES | SEE ALSO | NOTES