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

Groups > comp.unix.programmer > #1052 > unrolled thread

communicating sequential process and call processing threads

Back to article view | Back to comp.unix.programmer

Contents

  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

#1052 — communicating sequential process and call processing threads

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
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.

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

comp.unix.programmer

comp.programming.threads

thanks
ittium

[toc] | [next] | [standalone]

#1092

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.unix.programmer

csiph-web