From owner-state-threads@oss.sgi.com Wed Aug 1 11:02:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71I2V609268 for state-threads-outgoing; Wed, 1 Aug 2001 11:02:31 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71I2UV09265 for ; Wed, 1 Aug 2001 11:02:30 -0700 Received: from trudge.engr.sgi.com (trudge.engr.sgi.com [163.154.38.51]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA07576 for ; Wed, 1 Aug 2001 11:02:14 -0700 (PDT) mail_from (mja@trudge.engr.sgi.com) Received: (from mja@localhost) by trudge.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA74496; Wed, 1 Aug 2001 11:00:58 -0700 (PDT) From: mja@trudge.engr.sgi.com (Mike Abbott) Message-Id: <200108011800.LAA74496@trudge.engr.sgi.com> Subject: Re: Porting from POSIX threads to State Threads To: cjohnson@avamar.com (Claude Johnson) Date: Wed, 1 Aug 2001 11:00:57 -0700 (PDT) Cc: state-threads@oss.sgi.com In-Reply-To: from "Claude Johnson" at Jul 31, 2001 02:11:21 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk 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@sgi.com www.repbot.org/mike From owner-state-threads@oss.sgi.com Wed Aug 1 11:07:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71I75A09380 for state-threads-outgoing; Wed, 1 Aug 2001 11:07:05 -0700 Received: from avamar.com (vortex.undoo.com [209.19.65.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71I74V09377 for ; Wed, 1 Aug 2001 11:07:04 -0700 Received: from vortex.undoo.com (vortex.undoo.com [192.168.100.3]) by avamar.com (8.11.3/8.11.3) with ESMTP id f71I70L06794; Wed, 1 Aug 2001 11:07:00 -0700 (PDT) Date: Wed, 1 Aug 2001 11:07:00 -0700 (PDT) From: Claude Johnson X-Sender: cjohnson@vortex.undoo.com To: Mike Abbott cc: state-threads@oss.sgi.com Subject: Re: Porting from POSIX threads to State Threads In-Reply-To: <200108011800.LAA74496@trudge.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-state-threads@oss.sgi.com Precedence: bulk On Wed, 1 Aug 2001, Mike Abbott wrote: [*]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. Hmm, I was just looking at how to deal with a pthread_detach call. And since I'm not a programmer, this could take a while 8-) There are lots of wrapper methods for the pthread functions (did I mention this app is in C++). So.... [Lossy compression] [*]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. Yeah, this is a network server which is why ST looked compelling anyway. Thanx tho! [*]-- [*]Michael J. Abbott mja@sgi.com www.repbot.org/mike [*] Claude Johnson Network Scientist Avamar Technologies 949.743.5145 Vox 949.743.5190 Fax www.avamar.com