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

From "Naveen K. Kaushik" <naveenkumarkaushik@gmail.com>
Newsgroups comp.unix.programmer
Subject Re: communicating sequential process and call processing threads
Date 2011-08-09 10:50 +0530
Organization A noiseless patient Spider
Message-ID <4E40C384.1040606@gmail.com> (permalink)
References <2f06d6cc-ef49-471a-ab13-862951fe05ab@f39g2000prb.googlegroups.com>

Show all headers | 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