Much of the "cooked" file-handling stems from distributed erlang. (Which I now read Raimo explained so on to the next issue ...)<div><br></div><div>Transparent distributed access to a file-system or a fast local file-system?</div>
<div><br></div><div>Though a very nifty feature, one can certainly question the reasons for having a file-server being the default behavior in erlang. I would argue against this.</div><div><br></div><div>A (normal?) three tier solution would probably be better. </div>
<div>Tier 1: Gritty driver/nif interface to files. (prim_file) unstable api</div><div>Tier 2: local file acess (file) stable api</div><div>Tier 3: distributed access (not file)</div><div><br></div><div>At first glance Tier 1 and 2 could be collapsed to the same tier but that would not be ideal. I want the prim_* api to be changeable. (Which is the reason why it is not documented I believe)</div>
<div>For example, changing the #file_info file times to epochs instead of having *localtime* datetime tuples while the file module still can have its datetime tuples. (This is a change which probably will be in r15). </div>
<div><br></div><div>It is unlikely we would remove file-server from file and into a another abstraction layer, but the default behavior should be changed. And file should be extended with the functionality Raimo described. We should probably remove as much functionality as possible in the efile_driver and let higher tier (in erlang) take care of that. </div>
<div><br></div><div>Now if I only could find a time-machine or a pill that lets me work 36h a day.</div><div><br></div><div>// Björn-Egil</div><div>-- Concern for the past is hindering our future.</div><span class="Apple-style-span" style="font-family: sans-serif; font-size: 16px; line-height: 24px; background-color: rgb(255, 255, 255); "><h1 id="firstHeading" class="firstHeading" style="color: black; background-image: none; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: initial; margin-top: 0px; margin-right: 0px; margin-bottom: 0.1em; margin-left: 0px; overflow-x: hidden; overflow-y: hidden; padding-top: 0px; padding-bottom: 0px; border-bottom-width: 1px; border-bottom-style: solid; border-bottom-color: rgb(170, 170, 170); width: auto; font-size: 1.6em; line-height: 1.2em; ">
<br></h1></span><div><br></div><div><br></div><div><br></div><div><div class="gmail_quote">2011/9/27 Alexandru Scvorţov <span dir="ltr"><<a href="mailto:scvalex@gmail.com">scvalex@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Scott,<br>
<br>
Thanks a lot for the suggestion. We needed a few more functions than<br>
just read_file_info(), including a few from filelib (which used file<br>
internally). We ended up writing a few wrappers around the prim_file<br>
functions. We also had a bit of problem hitting the open files limit,<br>
but we already had a system in place to manage that.<br>
<br>
Thanks again,<br>
<br>
Alex<br>
<div><div></div><div class="h5"><br>
On Thu, Sep 15, 2011 at 01:24:48PM -0500, Scott Lystig Fritchie wrote:<br>
> Alexandru, I'm about to hop on a plane, so I don't have much time. Yes,<br>
> your analysis appears sound. There has been discussion in the last week<br>
> on the mailing list that is related to prim_file and the file_server_2<br>
> (registered proc name) process.<br>
><br>
> The probable answer (at least for now) is to write your own interface to<br>
> the prim_file:read_file_info() (name?) function so that you can take<br>
> advantage of the "+A n" I/O worker Pthread pool ... assuming of course<br>
> that your workload doesn't overwhelm them to the point where selective<br>
> receive doesn't bite you again.<br>
><br>
> -Scott<br>
><br>
><br>
_______________________________________________<br>
erlang-bugs mailing list<br>
<a href="mailto:erlang-bugs@erlang.org">erlang-bugs@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-bugs" target="_blank">http://erlang.org/mailman/listinfo/erlang-bugs</a><br>
</div></div></blockquote></div><br></div>