Re: What's the connection between objects and threads?
On 18 mai, 17:06, ManicQin <Manic...@gmail.com> wrote:
On May 18, 4:56 pm, James Kanze <james.ka...@gmail.com> wrote:
What are the constraints concerning shutdown? If you don't have
any (i.e. the only way to stop the process is to kill it), then
your connection threads are basically fire and forget: you don't
really need to keep any trace of them (which means that you
don't have any "thread" objects). In fact, unless the server
needs to access shared in memory data, it may be preferable to
use processes instead of threads. (That's what a lot of
traditional servers do: FTP, telnet, etc.)
When you say processes do you mean different processes running
and communicating via files\pipelines\sockets and so on?
When I say processes, I mean processes. Note too that I said
"unless the server needs to access shared in memory data". If
that's not the case, there is no need for communication between
the processes once they've been started.
1) Wont it just complicate things?
It depends. Under Unix, child processes inherit open files (and
a socket connection is an "open file" for Unix), so all you
really have to communicate is the file id, and you can
communicate that as a command line argument. (Note that you
*don't* go through system() to do this. You use fork and exec
directly.)
2) Darren is supposed to submit his project to his prof\tester
usually spliting your projects (IMHO) to sub processes gives
it a... (maybe unjustified) scent of a bad design... Most of
my professors were fixed on the notion that an application is
one process.
I'd suggest changing profs in that case---it's actually very,
very exceptional for an application to be a single process.
Especially a server: at the very least, there will be a shell
script which restarts it if it crashes.
(I think that spliting your process to subs is a concept that
is more acknowledged in linux \unix platforms then windows.
That may be because Unix was doing networking and Windows long
before Windows:-). The current mode seems to use threads for
everything---you see them when there's really no reason to be
multi-threaded, and you see them when separate processes are a
better solution. In many ways, threads are the worse of the
three solutions, and should only be used if there are strong
reasons why one of the other solutions cannot be used.
AFAIK it's partially due to the reason that in linux you only
load your code once for all the instances of the
application... or something like that... CMIIW!!!)
Actually, it's at least partially because under Unix, most of
the server applications predated threads. FTP and telnet were
around long before Windows even existed. But from a design
standpoint: separate processes are the ultimate encapsulation,
and encapsulation is normally a good thing.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34