design advice sought

Mongryong Mongryong at sympatico.ca
Sun Jan 26 12:03:59 EST 2003


In most cases, using processes instead of threads is a better solution. 
Yes, there's less overhead in thread context-switching then there is in
process context-switching but that doesn't mean that overall performance
of your "system" will be faster.  

The right solution is usually a factor of the amount of cohesion and
information hiding between your code.

You should consider processes when:
1) For functionality that has a high period.  That is, the functionality
is only needed once every hour or day.  This is typically of things an
os scheduler would run.

2) For functionality that only occurs once like at startup and cleanup.

3) For monitoring transducers (input and output signals).  For example,
in Windows, Windows watches for mouse and keyboard events.  If an event
is targeted for your process, Windows will send the event to your
message queue.  Here Windows is another process separate from your
process.  Another example is reading/writing from your hard-drive. While
the hard-drive performs the read/write the OS switches to another
application (process).

4) For functionality that is CPU intensive.  For example, a MP3
renderer.  Once the MP3 renderer has its parameters, it usually doesn't
depend on anything else to finish its job.

The main theme here with processes is "high information hiding, and low
cohesion."  

You should consider threads basically when there's "low information
hiding and high cohesion."  That is, your "processes" share a lot of
resources that can not be easily centralized and the interfaces between
your "proesses" is very complex.

Besides that, threads are much harder to develop and test because of the
dependencies that exist between them.  

This description is very brief, but hopefully it's enough to get you to
do some more research.

On Sun, 2003-01-26 at 01:43, Byron Morgan wrote:
> My project:
> 
> An existing server taps the logged output of a real-time control system,
> making the data available via inet.
> Platform is Python 2.2.2 on W2k.
> 
> My application (my first effort in Python) monitors the data stream,
> watching for critical events as well as maintaining status information on
> roughly 100 control subsystems. I have reached the point where it does this
> much pretty well, running all day. Next, I will add functions to send
> messages via various transports (e.g., pager, cellular text, instant
> mesaging) based on conditions and trends detected or analyzed.
> 
> I am seeking input on whether I should build all into a single app, which
> may necessitate the use of threading, or use one or more companion apps to
> handle the notification stuff. If separate applications are used, how best
> to communicate (I assume sockets will do, but have no experience with this,
> or with threads).
> 
> TIA,
> 
> Byron Morgan
> 
> 
> -- 
> http://mail.python.org/mailman/listinfo/python-list







More information about the Python-list mailing list