Petr Vandrovec wrote:Hmm.. I thought server->packet was protected until the packet was completed, independent of the process that issued it. Looking closer I see that this isn't quite the case. How about this... We allocate two buffers at startup, one for outgoing and one for incoming. Then we use these during the actual transmission, copying back and forth as need. Then we just need to avoid the final response copy if the process has gone belly up. Now my next question in that case is, what is the purpose of server->packet. Couldn't this buffer be provided by the caller like the response buffer? Rgds -- -- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
| Jeff Garzik | Re: fallocate-implementation-on-i86-x86_64-and-powerpc.patch |
git: | |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Arjan van de Ven | Re: [GIT]: Networking |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Natalie Protasevich | [BUG] New Kernel Bugs |
