I'm have been giving some thought to different approaches to scheduling
activities.  Here are some notes, for comment and discussion...

-r

* shared process

   All activities share a single process.  Process-level state (e.g.,
   nice(2) level) is common to all; program data may or may not be shared.

* call a subroutine

     This technique, used by POE, has the advantage of low start-up
     overhead.  Unfortunately, the multitasking is "cooperative" (ala Mac
     OS 9), rather then "pre-emptive".  So, if an activity doesn't play
     nicely, the entire subsystem gets dragged down.

     Because subroutines share a common name space for data, communication
     among the activities is easy.  Concurrency issues are (largely)
     avoided because only one subroutine can be running at a time.  If a
     subroutine "yields" control, however, care must be taken to ensure
     that its working data does not get compromised.

* spawn a thread

     In Perl's implementation, each thread has its own, independent, set
     of data.  Threads can share data, by agreement, but care must be
     taken to avoid deadlocks, etc.

* separate process

   Each activity has its own process.  Process-level state (e.g., nice(2)
   level) and program data are not shared.

* fork(2), then exec(2) a new program

     This technique, used by cron(8), provides complete independence for
     each activity.  The program may be written in an arbitrary language,
     have its own nice(2) level, etc.

     The drawback is that the exec(2) and subsequent start-up activities
     are quite time-consuming; if we're doing a lot of this, the overhead
     will be substantial.

* fork(2) the process, then call a subroutine

     This technique, used by many system daemons, takes advantage of the
     fact that fork(2) is a highly-optimized mechanism on BSD systems.
     Although each process acts as if it has independent state, only a
     small amount of information must be copied initially; the remainder
     is copied (via "copy on write" facilities) if and when the processes
     diverge.

     If the parent Perl script loads (via require) all of the routines
     that any of the children will need to call, the start-up overhead
     for the individual activities will be very small.
--
email: [EMAIL PROTECTED]; phone: +1 650-873-7841
http://www.cfcl.com/rdm    - my home page, resume, etc.
http://www.cfcl.com/Meta   - The FreeBSD Browser, Meta Project, etc.
http://www.ptf.com/dossier - Prime Time Freeware's DOSSIER series

Reply via email to