Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Actor.receiveWithin may block indefinitely #3838

Closed
scabug opened this issue Sep 13, 2010 · 4 comments
Closed

Actor.receiveWithin may block indefinitely #3838

scabug opened this issue Sep 13, 2010 · 4 comments
Assignees

Comments

@scabug
Copy link

scabug commented Sep 13, 2010

According to the documentation, receiveWithin should block at most msec milliseconds
if no message matches any of the cases of the partial function passed as argument.

This is not correct if the function is not defined on TIMEOUT and if the msec argument
is > 0.

The function

def main(args: Array[String]){
	Actor.receiveWithin(0) {
		case str: String => println(str)
	}
}

throws an "unhandled timeout" RuntimeException, however

def main(args: Array[String]){
	Actor.receiveWithin(1) {
		case str: String => println(str)
	}
}

blocks indefinitely. The TIMEOUT object is stored in the mailbox after the timeout, but it remains there as it is not consumed.
Actually a new TIMEOUT object is added to the mailbox after each additional msec milliseconds.

The function receiveWithin defines the local function receiveTimeout which checks, whether the function is defined at TIMEOUT, but this function is only called if msec == 0L.

Dominik

@scabug
Copy link
Author

scabug commented Sep 13, 2010

Imported From: https://issues.scala-lang.org/browse/SI-3838?orig=1
Reporter: @dgruntz

@scabug
Copy link
Author

scabug commented Sep 13, 2010

@paulp said:
This sounds like a duplicate of #3799, but not sure: perhaps submitter could see if that sounds true and if so, close this as a duplicate.

@scabug
Copy link
Author

scabug commented Sep 14, 2010

@dgruntz said:
Replying to [comment:1 extempore]:

This sounds like a duplicate of #3799, but not sure:
perhaps submitter could see if that sounds true and if so,
close this as a duplicate.
#3799 reports, that messages may be lost. In my example no message is lost, all messages remain in the actor's mailbox, but receiveWithin does not terminate after the timeout. Actually, the TIMEOUT message can be found in the mailbox. Note that this behavior changed from 2.7.7 to 2.8.0.

=> no duplicate.

@scabug
Copy link
Author

scabug commented Mar 15, 2011

@phaller said:
(In r24466) Closes #3838. Review by prokopec.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants