NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/unix/programm/6071

Text File | 1993-01-28 | 3.4 KB | 70 lines

Newsgroups: comp.unix.programmer
Path: sparky!uunet!ferkel.ucsb.edu!taco!gatech!paladin.american.edu!howland.reston.ans.net!usc!sdd.hp.com!decwrl!pa.dec.com!engage.pko.dec.com!nntpd.lkg.dec.com!news!alpha.aosg.gsf.dec.com!gaf
From: [e-mail] (Gerald Feldman)
Subject: Re: client/server question.....
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News System)
Nntp-Posting-Host: alpha.aosg.gsf.dec.com
Reply-To: [e-mail]
Organization: Digital Equipment Corporation
References: <[e-mail]> <[e-mail]>
Date: Wed, 27 Jan 1993 22:31:24 GMT
Lines: 56

In article <[e-mail]>, [e-mail] (Anay Panvalkar) writes:
|> In article <[e-mail]> [e-mail] (ARIT ISMAIL) writes:
|>
|> >I don't want to fork because the info should be generated on one
|> >program, send to server and the server has to respond to every
|> >program connected with the same info( if I fork, how can I transfer
|> >that info to child?).
|>
|> One solution is open a temp. file and write your info to it.
|> Then when you fork() the child will get its own copy of the
|> parent's descriptors. But, if the child modifies this info,
|> it will affect any later read or writes to it by the parent.
|>
|> > check_new_connection(); /* how can I check if there is any new
|> >                           without waiting, as far as I know accept(..)
|> >                           blocks you 'till you get some connection*/
|>
|> Well, read the man page for select(2)...
|>      Selecting true for reading on a socket descriptor upon which
|>      a  listen(2) call has been performed indicates that a subse-
|>      quent accept(2) call on that descriptor will not block.
|>
|> >My problem is getting new connections without waiting.
|> >I appreciate any help.
|> >[e-mail]
|>
|> -Anay
|>
|> --
|> ===============================================================================
|> Anay S. Panvalkar
|> Biomedical Engineering                  ****GO TARHEELS****
|> University of North Carolina

--
Maybe a more appropriate solution is to use threads (or lightweight
processes). With threads, your program is viewed as a single process by
the OS (although the Kernel does know about Kernel threads). Also, if
you use Posix threads your application will be somewhat portable between
operating systems and platforms. Your application could be more easily
ported to Sun, Digital Unix (Ultrix or OSF/1), Digital VMS, HP-UX.
Your global memory is shared by each thread, but each thread has its own
stack. This approach eliminates keeping a temp file. It also eliminates
the non-portability of using a shared memory or IPC solution. The only
real problem is that the Posix threads standard is subject to change.
But, this is probably the most portable solution, and it does not lock
your application into anyone's hardware or OS since threads can be
implemented on many different types of operating systems.
+-------------------------------------------------------------+
Jerry Feldman           AOSG
Mailstop: GSF1-1/K13       DTN:264-5863
Digital Equipment Corp.    EXT:[phone]
5 Wentworth Drive          ip(DEC): [e-mail]
Hudson, NH 03051           enet: alpha::gaf
               Internet(HOME):[e-mail]
+-------------------------------------------------------------+