On 14/05/2015 12:25, Wouter Verhelst wrote: > Also, we should indeed stick to errno numbers for backwards > compatibility, but there's no reason why we wouldn't be able to create a > separate set of numbers (with a high bit set, e.g.) for errors that > can't be properly expressed with errno numbers, and I'm not sure if > mapping ENOMEM in this manner is a good idea.
Right. But ENOMEM technically could have happened before. > As to whether ENOMEM should be a fatal message in the protocol or not? > Not sure. I don't think so. Let the client worry about it. They can always decide to disconnect if they get ENOMEM, or they can get into a recovery mode with some kind of exponential backoff, or... And of course the server can always exit(1) if malloc returns NULL. Sticking policy into the protocol sounds like a road to people thinking they must be an exception and not following the documentation. > Thoughts? > >> - EDQUOT is not part of the universal set of errors; it can be changed >> to ENOSPC on the wire format. >> >> - EFBIG is part of the universal set of errors, but it is also changed >> to ENOSPC because it is pretty similar to ENOSPC or EDQUOT. > > Yeah, that makes sense. Good, that was the part that I was worried about. :) Paolo ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
