Date: Tue, 8 Feb 2005 17:10:28 -0800 From: Ben Woolley <ben@tautology.org> To: Pav Lucistnik <pav@FreeBSD.org>, ben@tautology.org, freebsd-ports-bugs@FreeBSD.org Subject: Re: ports/77186: Update port: devel/sendfile to 1.2.1 Message-ID: <20050209011028.GE74916@tautology.org> In-Reply-To: <200502082035.j18KZa4b033712@freefall.freebsd.org> References: <200502082035.j18KZa4b033712@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Sorry for the non-standard submission. Here you go. :) Thank you.=20 diff -ruN py-sendfile.old/Makefile py-sendfile/Makefile --- py-sendfile.old/Makefile Sun Feb 6 14:45:23 2005 +++ py-sendfile/Makefile Sun Feb 6 16:30:40 2005 @@ -6,7 +6,7 @@ # =20 PORTNAME=3D sendfile -PORTVERSION=3D 1.2 +PORTVERSION=3D 1.2.1 CATEGORIES=3D devel python MASTER_SITES=3D http://tautology.org/software/python-modules/distfiles/ PKGNAMEPREFIX=3D ${PYTHON_PKGNAMEPREFIX} diff -ruN py-sendfile.old/distinfo py-sendfile/distinfo --- py-sendfile.old/distinfo Sun Feb 6 14:45:23 2005 +++ py-sendfile/distinfo Tue Feb 8 16:55:11 2005 @@ -1,2 +1,2 @@ -MD5 (py-sendfile-1.2.tar.bz2) =3D be1b00596f73951a453858a406803817 -SIZE (py-sendfile-1.2.tar.bz2) =3D 3825 +MD5 (py-sendfile-1.2.1.tar.bz2) =3D acefec93919ce80dc8222310fdd411e3 +SIZE (py-sendfile-1.2.1.tar.bz2) =3D 3836 diff -ruN py-sendfile.old/files/patch-sendfilemodule.c py-sendfile/files/pa= tch-sendfilemodule.c --- py-sendfile.old/files/patch-sendfilemodule.c Sun Feb 6 14:45:24 2005 +++ py-sendfile/files/patch-sendfilemodule.c Wed Dec 31 16:00:00 1969 @@ -1,77 +0,0 @@ ---- sendfilemodule.c.orig Sun Feb 6 13:17:43 2005 -+++ sendfilemodule.c Sun Feb 6 23:41:08 2005 -@@ -174,40 +174,40 @@ -=20 - static PyMethodDef SendfileMethods[] =3D { - {"sendfile", method_sendfile, METH_VARARGS, --"sendfile(out_fd, in_fd, offset, count) =3D [position, sent] -- --FreeBSD only: --sendfile(out_fd, in_fd, offset, count, headers_and_or_trailers) =3D [posi= tion, sent] -- --Direct interface to FreeBSD and Linux sendfile(2) using the Linux API, ex= cept that errors are turned into Python exceptions, and instead of returnin= g only the amount of data being sent, it returns a tuple that contains the = new file pointer, and the amount of data that has been sent.=20 -- --For example: -- --from sendfile import * --sendfile(out_socket.fileno(), in_file.fileno(), int_start, int_len) -- --On Linux, item 0 of the return value is always a reliable file pointer. T= he value specified in the offset argument is handed to the syscall, which t= hen updates it according to how much data has been sent. The length of data= sent is returned in item 1 of the return value. -- --FreeBSD sf_hdtr is also supported as an additional argument which can be = a string, list, or tuple. If it is a string, it will create a struct iovec = of length 1 containing the string which will be sent as the header. If a li= st, it will create a struct iovec of the length of the list, containing the= strings in the list, which will be concatenated by the syscall to form the= total header. If a tuple, it will expect a string or list of strings in tw= o items: the first representing the header, and the second representing the= trailer, processed the same way as the header. You can send only a footer = by making the header an empty string or list, or list of empty strings. -- --FreeBSD example with string header: -- --from sendfile import * --sendfile(out_socket.fileno(), in_file.fileno(), 0, 0, \"HTTP/1.1 200 OK\\= r\\nContent-Type: text/html\\r\\nConnection: close\\r\\n\\r\\n\") -- --FreeBSD example with both header and trailer as a string: -- --from sendfile import * --sendfile(out_socket.fileno(), in_file.fileno(), int_start, int_len, ('BEG= IN', 'END')) -- --FreeBSD example with mixed types: -- --from sendfile import * --sendfile(out_socket.fileno(), in_file.fileno(), int_start, int_len, ([mag= ic, metadata_len, metadata, data_len], md5)) -- --Although the FreeBSD sendfile(2) requires the socket file descriptor to b= e specified as the second argument, this function will ALWAYS require the s= ocket as the first argument, like Linux and Solaris. Also, if an sf_hdtr is= specified, the function will return the total data sent including all of t= he headers and trailers. Note that item 0 of the return value, the file poi= nter position, is determined on FreeBSD only by adding offset and count, so= if not all of the data has been sent, this value will be wrong. You will h= ave to use the value in item 1, which tells you how much total data has act= ually been sent, and be aware that header and trailer data are included in = that value, so you may need to reconstruct the headers and/or trailers your= self if you would like to find out exactly which data has been sent. Howeve= r, if you do not send any headers or trailers, you can just add item 1 to w= here you started to find out where you need to start from again. I do not c= onsider this much of a problem because if you are sending header and traile= r data, the protocol will likely not allow you to just keep sending from wh= ere the failure occured without getting into complexities, anyway.=20 -- --The variable has_sf_hdtr is provided for determining whether sf_hdtr is s= upported."}, -+"sendfile(out_fd, in_fd, offset, count) =3D [position, sent]" -+"" -+"FreeBSD only:" -+"sendfile(out_fd, in_fd, offset, count, headers_and_or_trailers) =3D [pos= ition, sent]" -+"" -+"Direct interface to FreeBSD and Linux sendfile(2) using the Linux API, e= xcept that errors are turned into Python exceptions, and instead of returni= ng only the amount of data being sent, it returns a tuple that contains the= new file pointer, and the amount of data that has been sent. " -+"" -+"For example:" -+"" -+"from sendfile import *" -+"sendfile(out_socket.fileno(), in_file.fileno(), int_start, int_len)" -+"" -+"On Linux, item 0 of the return value is always a reliable file pointer. = The value specified in the offset argument is handed to the syscall, which = then updates it according to how much data has been sent. The length of dat= a sent is returned in item 1 of the return value." -+"" -+"FreeBSD sf_hdtr is also supported as an additional argument which can be= a string, list, or tuple. If it is a string, it will create a struct iovec= of length 1 containing the string which will be sent as the header. If a l= ist, it will create a struct iovec of the length of the list, containing th= e strings in the list, which will be concatenated by the syscall to form th= e total header. If a tuple, it will expect a string or list of strings in t= wo items: the first representing the header, and the second representing th= e trailer, processed the same way as the header. You can send only a footer= by making the header an empty string or list, or list of empty strings." -+"" -+"FreeBSD example with string header:" -+"" -+"from sendfile import *" -+"sendfile(out_socket.fileno(), in_file.fileno(), 0, 0, \"HTTP/1.1 200 OK\= \r\\nContent-Type: text/html\\r\\nConnection: close\\r\\n\\r\\n\")" -+"" -+"FreeBSD example with both header and trailer as a string:" -+"" -+"from sendfile import *" -+"sendfile(out_socket.fileno(), in_file.fileno(), int_start, int_len, ('BE= GIN', 'END'))" -+"" -+"FreeBSD example with mixed types:" -+"" -+"from sendfile import *" -+"sendfile(out_socket.fileno(), in_file.fileno(), int_start, int_len, ([ma= gic, metadata_len, metadata, data_len], md5))" -+"" -+"Although the FreeBSD sendfile(2) requires the socket file descriptor to = be specified as the second argument, this function will ALWAYS require the = socket as the first argument, like Linux and Solaris. Also, if an sf_hdtr i= s specified, the function will return the total data sent including all of = the headers and trailers. Note that item 0 of the return value, the file po= inter position, is determined on FreeBSD only by adding offset and count, s= o if not all of the data has been sent, this value will be wrong. You will = have to use the value in item 1, which tells you how much total data has ac= tually been sent, and be aware that header and trailer data are included in= that value, so you may need to reconstruct the headers and/or trailers you= rself if you would like to find out exactly which data has been sent. Howev= er, if you do not send any headers or trailers, you can just add item 1 to = where you started to find out where you need to start from again. I do not = consider this much of a problem because if you are sending header and trail= er data, the protocol will likely not allow you to just keep sending from w= here the failure occured without getting into complexities, anyway. " -+"" -+"The variable has_sf_hdtr is provided for determining whether sf_hdtr is = supported."}, - {NULL, NULL, 0, NULL} /* Sentinel */ - }; -=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050209011028.GE74916>