Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.unix.programmer > #1092
| 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> |
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
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