[ новости /+++ | форум | теги | ]

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, desig-
           nated 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 unde-
     tached 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 con-
     text parameter so that the new LWP begins executing a  func-
     tion.

     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.

Партнёры:

Хостинг: