Have this even been decided? Roland and I discussed it this morning. But couldn't come to a good conclusion.

I think it should be addressed since it's causing problems for users, so either it's fixable, and then we should do it, or it's not fixable and we should close it as invalid. This ticket could go either way, but I want to try it out before dismissing it. It's not highest prio, but it would be good to have fixed.

Sounds good.

(In revision:a111bc629f1293986a19b11f475360324ed83da9) make system.actorOf non-blocking (*), see #2031

(*) that actually depends on whether provider.actorOf blocks, which
currently MAY happen when actor creation triggers a remote connection

- properly CAS childrenRefs within ActorCell, making it safe to update
from the outside
- add reserve/unreserve to ChildrenContainer and move uniqueness check
there
- when creating, first reserve, then add the actor; unreserve if
provider.actorOf did fail

Branch: wip-2031-sync-actorOf-∂π

(In revision:cd9cc6a44b778dce809d584dcc59306a7b6afda4) make system.actorOf non-blocking (*), see #2031

(*) that actually depends on whether provider.actorOf blocks, which
currently MAY happen when actor creation triggers a remote connection

- properly CAS childrenRefs within ActorCell, making it safe to update
from the outside
- add reserve/unreserve to ChildrenContainer and move uniqueness check
there
- when creating, first reserve, then add the actor; unreserve if
provider.actorOf did fail

Branch: wip-2031-sync-actorOf-2.0-∂π

(In revision:df89184b30c5eedd17ee1c131322f6677accabc6) make system.actorOf non-blocking (*), see #2031

(*) that actually depends on whether provider.actorOf blocks, which
currently MAY happen when actor creation triggers a remote connection

- properly CAS childrenRefs within ActorCell, making it safe to update
from the outside
- add reserve/unreserve to ChildrenContainer and move uniqueness check
there
- when creating, first reserve, then add the actor; unreserve if
provider.actorOf did fail

Branch: wip-2031-sync-actorOf-3.0-∂π

(In revision:b60210362e089a4df97d18ded0bfc693bf800a7c) make system.actorOf() non-blocking (and working), see #2031

- introducing RepointableActorRef, which starts out with an
UnstartedActorCell which can cheaply be created; the Supervise()
message will trigger child.activate() in the supervisor, which means
that the actual creation (now with normal ActorCell) happens exactly
in the right place and with the right semantics. Messages which were
enqueued to the dummy cell are transferred atomically into the
ActorCell (using normal .tell()), so message sends keep working
exactly as they used to
- this enables getting rid of the brittle synchronization around
RoutedActorRef by replacing that one with a RepointableActorRef
subclass which creates RoutedActorCells upon activate(), with the nice
benefit that there is no hurry then to get it right because the new
cell is constructed “on the side”

misc fixes:

- InvalidMessageException is now actually enforced when trying to send
“null”
- Mailboxes may be created without having an ActorCell, which can come
in handy later, because the cell is only needed when this mailbox is
going to be scheduled on some executor
- remove occurrences of Props(), which is equivalent to Props[Nothing],
which is equivalent to «bug»
- add test case which verifies that context.actorOf is still synchronous
- plus all the stuff I have forgotten.

Branch: wip-2031-sync-actorOf-3.0-∂π

(In revision:422cf386c8ba5fefd2c17f144386a8fbd964083f) incorporate review comments, add docs, see #2031

also add Java sample for creating custom MailboxType

Branch: wip-2031-sync-actorOf-3.0-∂π

Updating tickets (#520, #852, #857, #874, #935, #950, #1364, #1508, #1542, #1559, #1734, #1744, #1755, #1782, #1812, #1824, #1831, #1858, #1871, #1880, #1886, #1892, #1896, #1899, #1929, #1930, #1950, #1952, #1953, #1962, #1966, #1969, #1972, #1973, #1977, #1978, #1986, #1988, #1993, #1999, #2000, #2003, #2005, #2006, #2015, #2016, #2019, #2021, #2022, #2023, #2024, #2025, #2029, #2031, #2032, #2036, #2046, #2048, #2051, #2055, #2059, #2061, #2062, #2064, #2065, #2068, #2072, #2074, #2076, #2078, #2079, #2085, #2087, #2088, #2089, #2090, #2091, #2092, #2093, #2095, #2098, #2099, #2100, #2101, #2102, #2119, #2129, #2134, #2135, #2136, #2144, #2147, #2148, #2156, #2166, #2168, #2172, #2174, #2178, #2183)