-
Notifications
You must be signed in to change notification settings - Fork 56
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
wedges system #9
Comments
For the record, I am seeing the same behaviour, |
Me too. R16B, Linux x86_64. |
I am willing to bet that the problem has to do with locking and how R16B handles ports differently (asynchronously) compared to R15B. I'll probably take a deeper look into the code tomorrow. |
Confirmed that it works in |
A debug version of the Erlang VM seems to have caught something:
|
Paging doctor @vinoski. |
Looking into it. |
Ok, a backtrace shows the problem occurs in The So the question is really if it is safe to have multiple callers executing inside the syslog_drv.c code. |
See this thread for further details (as well as nice explanation from @jlouis): Vagabond/erlang-syslog#9 Signed-off-by: Peter Lemenkov <lemenkov@gmail.com>
I have been looking tinto this some more. There are concerns with the fix @lemenkov proposed I think. The concern is that One possible solution is to protect the necessary syslog calls by a mutex, so only one scheduler is able to operate on the call itself at a time. This would mend the race window, but the change is a bit more involved then to fix. |
I have a completely different fix that refactors the code to move the port creation out of the C code up into Erlang instead. I think it simplifies everything. |
With R16B changes related to locking within the area of port drivers seemed to result in the syslog driver hanging on the driver_create_port call. To avoid this, move port creation and closing from C into Erlang. Rework the driver control interface to simplify the open call to just the setting of the logopt and facility on a new port. Remove the opening and closing of a port in the gen_server init and terminate as that port is no longer needed to communicate with the driver. Move the open call out of the gen_server and do it in the caller's process instead.
I like your fix better than mine. It is a move in a direction I like more than introducing more mutexes. |
Just thought I'd mention here as well that @vinoski 's code appears to work for me, too, although now I'm a bit gunshy of using a compiled in port... |
I am running it in production as well and it looks like it works fine. |
move port creation to Erlang to fix issue #9
Thanks to @vinoski this has been fixed, it seems. |
I'm pretty sure I must be doing something wrong, but this code makes my system hang when I try and run it:
At this point it just hangs. I tracked things down in the C code to where it does this:
But I have no idea what it locks up there. I suspect I'm doing something wrong, but it'd be nice if I got a gentle message rather than a hung system.
The text was updated successfully, but these errors were encountered: