Ulf Wiger comments

Results 135 comments of


                                            Ulf Wiger

gproc_dist hangs on leader election for new nodes

I'll look into this. I'm leaving for a trip to the US today, which will either mean that I'll find some time, or have less time - not sure yet.

Question on loading new/stale property with get_env

Well, if you use `gproc:get_env()` consistently, gproc will always go back to the source. If you use `gproc:get_set_env()`, gproc will cache the result (even `undefined` if the value isn't found)....

gproc_pool:claim doesn't return worker when calling process is killed

It's true that the code doesn't handle the case of a process inside a claim operation gets killed from the outside. Strictly speaking, this is a bug. Fixing it will...

gproc_pool:claim doesn't return worker when calling process is killed

Describing it to my son, I came up with some failure scenarios that seem very hard to address. Basically, the approach _is_ inherently vulnerable to the calling process being murdered...

gproc_pool:claim doesn't return worker when calling process is killed

(This would be a good time to play around with QuickCheck/Pulse ...)

gproc_pool:claim doesn't return worker when calling process is killed

Since it certainly is an improvement over the previous implementation, I decided to merge. We can try to eliminate the (very slight) holes in the algorithm later.

gproc_pool:claim doesn't return worker when calling process is killed

I thought about that, but it complicates things, is not inherently safe, and also introduces significant latency (assuming the monitoring process always does the reset). It would probably at least...

gproc:reg({Type, l|g, Name}, ProcessPID)

See https://github.com/uwiger/gproc/blob/master/doc/gproc.md#reg-3

Too many timeout gen_leader leader_call error raised even though nodes are still connected.

Currently, there's no way to do this. I agree it would be nice feature to have.

Too many timeout gen_leader leader_call error raised even though nodes are still connected.

It's of course not an Erlang-specific issue that stale data remaining in memory can cause problems. ;-) I'll see if I can figure out why the replication sometimes fails, and...