|
|
| Author |
Message |
|
| ngunder |
 Posted: Wed Aug 01, 2007 8:49 am |
 |
|
|
Joined: 01 Aug 2007
Posts: 3
Location: Denmark
|
I thought I would start up this forum to discuss any timing issues that people have had when communicating using OTP.
I have just seen an issue where I have started two gen_fsm processes. After they have been started by a supervisor process, I kickoff an event message to one asking it to send an event message to the other. However, the second event message never reaches the other process and there is no exceptions reported. I have not root caused the issue, but I assume it has something to do with the mailboxes of both processes needing a bit more time to be setup . I fixed this issue by adding a timer:sleep() call in the caller process to give the other process a bit more time to be ready to receive the message.
Very strange. Has anyone seen something similar? |
|
|
| Back to top |
 
|
| francesco |
| Posted: Wed Aug 01, 2007 11:26 am |
|
|
|
User
Joined: 07 Jul 2006
Posts: 249
Location: London
|
It sounds like your problem has to do with order of operations. A supervisor works in a deterministic manner. It will start up a child at the time, starting the next one only when the previous one has successfully returned from its init function. If a child fails in its init function, the supervisor will itsself terminate. A mailbox is created as soon as the process is created and there is no need to initialise it, so that should not be your problem.
Questions:
Are you starting your behaviours with a supervisor?
Are you sure both behaviours have returned from their init call-back function before you generate the first event?
Are you using registered names? If not, how does the first behaviour get hold of the PID of the second behaviour?
Francesco |
|
|
| Back to top |
|
| ngunder |
| Posted: Wed Sep 26, 2007 1:12 pm |
|
|
|
Joined: 01 Aug 2007
Posts: 3
Location: Denmark
|
Hi Francesco,
Thanks for the quick responce. Sorry for my late responce, I was not sure how quick these posts were checked, but with a 3 hour return time, I will try to be more active on the forums here.
Quote: Are you starting your behaviours with a supervisor?
Yes
Quote: Are you sure both behaviours have returned from their init call-back function before you generate the first event?
No. What if one was sending an event to the other during its init() function call?
Quote: Are you using registered names? If not, how does the first behaviour get hold of the PID of the second behaviour?
Yes, {local, ?Module}. |
|
|
| Back to top |
|
| francesco |
| Posted: Mon Oct 15, 2007 4:36 pm |
|
|
|
User
Joined: 07 Jul 2006
Posts: 249
Location: London
|
Quote: Thanks for the quick responce. Sorry for my late responce, I was not sure how quick these posts were checked, but with a 3 hour return time, I will try to be more active on the forums here.  Sorry for breaking the record. We have been swamped, and neglected this forum...
Quote:
No. What if one was sending an event to the other during its init() function call?
This might be your problem. init/1 in your behaviour will be the next callback function to be called, but how do you know it has actually being called when you send the message?
If FSM A sends a message to FSM B, first start FSM B, then FSM A, as there is an obvious dependency between them. Is this what you are doing?
Francesco (Who promises to be more prompt)
--
http://www.erlang-consulting.com |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
