Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming.threads > #495
| From | "Naveen K. Kaushik" <naveenkumarkaushik@gmail.com> |
|---|---|
| Newsgroups | comp.programming.threads |
| Subject | Re: communicating sequential process and call processing threads |
| Date | 2011-08-09 10:57 +0530 |
| Organization | A noiseless patient Spider |
| Message-ID | <4E40C52E.2070803@gmail.com> (permalink) |
| References | <aa5add76-3ce9-4c8e-921e-0cdd9c4d6364@j9g2000prj.googlegroups.com> |
On 03-08-2011 PM 03:22, 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 transaction. Co routines are difficult to debug. "Go" from google uses some of the CSP concept so it may be a good language for your problem. Also keep in mind that, in a google test, "go" performed badly, C++ was the best language. > Because of the relevance I am posting the message to following groups. > > comp.unix.programmer > > comp.programming.threads > Avoid multiposting, use cross posting. Naveen > thanks > ittium
Back to comp.programming.threads | 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:52 -0700 Re: communicating sequential process and call processing threads "Naveen K. Kaushik" <naveenkumarkaushik@gmail.com> - 2011-08-09 10:57 +0530
csiph-web