doc: Update docs about new thread model
spdk_app_start no longer creates threads and appropriate docs should be updated. Signed-off-by: Maciej Szwed <maciej.szwed@intel.com> Change-Id: I29736e26faa6a3250a6019e90d9734ff04f6e1fd Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/518 Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com> Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Reviewed-by: Paul Luse <paul.e.luse@intel.com>
This commit is contained in:
parent
62ded32fd7
commit
71ccea94ce
@ -117,14 +117,10 @@ framework for all of the example applications it shipped with, in the interest
|
||||
of supporting the widest variety of frameworks possible. But the applications do
|
||||
of course require something that implements an asynchronous event loop in order
|
||||
to run, so enter the `event` framework located in `lib/event`. This framework
|
||||
includes things like spawning one thread per core, pinning each thread to a
|
||||
unique core, polling and scheduling the lightweight threads, installing signal
|
||||
handlers to cleanly shutdown, and basic command line option parsing. When
|
||||
started through spdk_app_start(), the library automatically spawns all of the
|
||||
threads requested, pins them, and is ready for lightweight threads to be
|
||||
created. This makes it much easier to implement a brand new SPDK application and
|
||||
is the recommended method for those starting out. Only established applications
|
||||
should consider directly integrating the lower level libraries.
|
||||
includes things like polling and scheduling the lightweight threads, installing
|
||||
signal handlers to cleanly shutdown, and basic command line option parsing.
|
||||
Only established applications should consider directly integrating the lower
|
||||
level libraries.
|
||||
|
||||
# Limitations of the C Language
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user