state-threads
[Top] [All Lists]

Re: Porting from POSIX threads to State Threads

To: cjohnson@xxxxxxxxxx (Claude Johnson)
Subject: Re: Porting from POSIX threads to State Threads
From: mja@xxxxxxxxxxxxxxxxxxx (Mike Abbott)
Date: Wed, 1 Aug 2001 11:00:57 -0700 (PDT)
Cc: state-threads@xxxxxxxxxxx
In-reply-to: <Pine.GSO.4.05.10107301637010.3714-100000@vortex.undoo.com> from "Claude Johnson" at Jul 31, 2001 02:11:21 AM
Sender: owner-state-threads@xxxxxxxxxxx
Unless your pthreaded application is fairly simple I would imagine that
converting it to state threads would probably require redesigning it
from scratch.  But since state threads are so much simpler to use than
pthreads the mechanics of the switch should be pretty easy.  You won't
need mutexes any more.  You won't have to bother with pthread_attr_t's
and other barfage.  You will need to ensure that every blocking I/O call
uses its st_ wrapper.

Personally, the hardest part about switching from pthreads to state
threads was just wrapping my brain around how simple and elegant state
threads are.  No race conditions - they're impossible!  Static variables
are OK!  No need for reentrant or thread-safe library functions!  After
years of painstakingly guarding data with mutexes it was hard to let go
of them.  Remember this mantra:  If your state threaded application uses
ANY mutexes, you're probably doing something wrong.

All that being said, state threads are not appropriate for every
application.  Remember this mantra too:  State threads are best for
network data driven apps.  Pthreads may work better for other kinds of
jobs.
-- 
Michael J. Abbott        mja@xxxxxxx        www.repbot.org/mike

<Prev in Thread] Current Thread [Next in Thread>