[erlang-patches] Optimize communication with file io server

[Anthony Ramine]

Fine with me but I hope that doesn't mean the two other patches will be ignored :p

I've amended the commit, please refetch.

Regards,

-- 
Anthony Ramine

Le 11 avr. 2013 à 12:36, Björn Gustavsson a écrit :

> Good work on making the optimization compatible.
> 
> To make this patch independent of the compiler
> patches, may I suggest that you remove wait_file_reply/1
> and rewrite file_request/2 like this:
> 
> file_request(Io, Request) ->
>     Ref = erlang:monitor(process, Io),
>     Io ! {file_request,self(),Ref,Request},
>     receive
> 	{file_reply,Ref,Reply} ->
> 	    erlang:demonitor(Ref, [flush]),
> 	    Reply;
> 	{'DOWN', Ref, _, _, _} ->
> 	    {error, terminated}
>     end.
> 
> 
> 
> On Wed, Apr 10, 2013 at 12:29 AM, Anthony Ramine <n.oxyde@REDACTED> wrote:
> Hello Björn,
> 
> I found a way to make it backwards compatible with the old protocol right now.
> 
> The file module communicates with a file io server with the following protocol for file operations:
> 
> > {file_request,From,ReplyAs,Request}
> < {file_reply,ReplyAs,Reply}
> 
> The ReplyAs value is sent by the client side to match against when receiving the reply and is otherwise left untouched and passed as is by the server.
> 
> The amended commit changes the protocol to:
> 
> > {file_request,From,MonitorRef,Request}
> < {file_reply,MonitorRef,Reply}
> 
> As the shape of the messages is not changed, backwards compatibility is not a concern.
> 
> Unfortunately, the following patch fails to compile because of a bug in the optimization pass. I've submitted two other patches; the first fixes beam_receive by teaching it how to track a set of registers instead of a single one, making it able to cope with the Core Erlang code generated by the inliner, the second improves sys_core_fold and makes it simplifies what is outputted by said inliner.
> 
> Please refetch.
> 
> Regards,
> 
> --
> Anthony Ramine
> 
> Le 9 avr. 2013 à 12:12, Björn Gustavsson a écrit :
> 
> > The patch looks fine and it would be a good thing to do.
> >
> > Unfortunately, there is the pesky question of backward
> > compatibility.
> >
> > Someone can open a file on an R15 system, send the
> > file descriptor (=a pid) to an R16B01 system with your
> > patch and the R16B01 system will attempt to do file
> > operations on the file.
> >
> > The backward compatible way to do this is to first introduce
> > a file_io_server module that can handle both the new
> > and the old messages. Two releases later the file module
> > can be changed to use the new message format.
> >
> > Strictly speaking, two releases forward means R19
> > to allow the original R16B release to communicate
> > with an R18 release.
> >
> > /Bjorn
> 
> 
> 
> 
> -- 
> Björn Gustavsson, Erlang/OTP, Ericsson AB