<div dir="ltr"><div><div>I'm assuming that it is expected behavior that the 21-rc1 tarball was removed from the downloads directory (The windows binaries are still there btw, as is the README).<br><br></div>I found this because I ran `kerl update releases` and to my surprise it wasn't there today, whereas in the weekend it was.<br><br></div>Is this an oversight, or should I await further development as things need to move around some more?<br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, May 7, 2018 at 10:00 AM Lukas Larsson <<a href="mailto:lukas@erlang.org">lukas@erlang.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello,<br><div class="gmail_extra"><br><div class="gmail_quote"></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, May 4, 2018 at 7:23 PM, Michał Muskała <span dir="ltr"><<a href="mailto:michal@muskala.eu" target="_blank">michal@muskala.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div>
<div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">The release looks great. Thank you to the whole OTP team for the work you put into it.</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Thanks!</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
<div><br></div>
<div>I wonder about the new file implementation that uses NIFs instead of ports, specifically the instrumentation around it. With ports, there was a way to list all ports and filter those that are files. This proved sometimes useful in debugging situations. Would it be possible to also get some kind of API to list all opened files, possibly with some additional information (like path)?</div>
<div>I imagine a need for an API like that would be even more pressing once sockets are ported to use NIFs instead of ports as well.</div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Yes, I also believe that something like this is going to be needed. While it is possible on most OSs to look in the /proc/ fs to see which files are opened, it is definitely useful to be able to track back to the process controlling it. Even more so for sockets.</div><div><br></div><div>Personally I would prefer not to have to build something new within erts to handle this, but instead use what we have. Maybe ets tables that keeps track of files, connections, etc. </div><div><br></div><div>Each sockets will most likely have to be associated with a process, so for them it could be possible to just store something in the process dictionary and let the debug process get the pdict of all processes.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Lukas</div><div><br></div></div></div></div>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>