Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.unix.programmer > #1092

Re: communicating sequential process and call processing threads

Path csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail
From "Naveen K. Kaushik" <naveenkumarkaushik@gmail.com>
Newsgroups comp.unix.programmer
Subject Re: communicating sequential process and call processing threads
Date Tue, 09 Aug 2011 10:50:04 +0530
Organization A noiseless patient Spider
Lines 53
Message-ID <4E40C384.1040606@gmail.com> (permalink)
References <2f06d6cc-ef49-471a-ab13-862951fe05ab@f39g2000prb.googlegroups.com>
Mime-Version 1.0
Content-Type text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding 7bit
Injection-Info mx04.eternal-september.org; posting-host="Jr+GCtWa+XbvmSdRpa1MLQ"; logging-data="17549"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19MyjzSTYDjStFjaj3e8F9HsOeqLCJRSsjmEkPLGCeSlw=="
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
In-Reply-To <2f06d6cc-ef49-471a-ab13-862951fe05ab@f39g2000prb.googlegroups.com>
Cancel-Lock sha1:mdPZJbh9Tbxy/dfLtXgCpUw7Os4=
Xref x330-a1.tempe.blueboxinc.net comp.unix.programmer:1092

Show key headers only | View raw


On 03-08-2011 PM 03:23, itt ium wrote:
> Group,
> I am designing a call processing module loosely based on communicating
> sequential process (CSP).
> The call has well defined state machine. Most of the state changes are
> done when some message is
> received from some other network node. Currently the call process is
> devided in to multiple stages
> whenever process needs to wait for some event (like sending message to
> node/waiting for message from node with non-blocking sockets), a new
> stage is defined i.e socket read/write calls  are boundary for these
> stages.
>
> Whenever an event (like respone from some node) takes place,
> appropriate stage map is searched and processing starts from there.
> These events are received through some edge triggered mecahanism and a
> thread that read from the fd will try to cross as many stages as
> possible.
>
>   My question is
>
> 1 Is this model correct

In CSP models that I have seen, people keeps queue of requests at 
different stages (and not the map). Also make sure, mutexes are evenly 
distributed between stages. I will encourage you to read

http://pl.atyp.us/content/tech/servers.html

which touches some of these concepts.

> 2.Should I have processing threads per stage or global thread pool
> 3 I might like to define more stages in future. What can be guidelines
> for defining stages that are not based of read/write calls.
> 3. Google go language avoids need for state machine by defining
> goroutines (similar to co-routine). In my opinion, I can avoid
> coroutines/goroutine/fibers by state machine and non-blocking calls.
>

Threads are processing unit,  Idea of specialized thread may not be 
good. But if there is a thread pool, there should we some way for 
threads to find out current stage of trasaction.

> Because of the relevance I am posting the message to following groups.
>

> comp.unix.programmer
>
> comp.programming.threads

Avoid multiposting, use cross posting.

Naveen

Back to comp.unix.programmer | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

communicating sequential process and call processing threads itt ium <ittium@gmail.com> - 2011-08-03 02:53 -0700
  Re: communicating sequential process and call processing threads "Naveen K. Kaushik" <naveenkumarkaushik@gmail.com> - 2011-08-09 10:50 +0530

csiph-web