| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Notes:
svn path=/head/; revision=55950
|
| |
|
|
|
|
|
|
|
|
|
|
| |
try to use writev(2) in a non-blocking mode, especially on sockets. Not only
this makes handling of EAGAIN rather weird, but in the case of sockets makes
your code subject of a ENOBUFS, which is absolutely unclear how to handle
properly. *sigh*
Bump PORTREVISION.
Notes:
svn path=/head/; revision=49333
|
| |
|
|
| |
Notes:
svn path=/head/; revision=49320
|
| |
|
|
|
|
|
|
|
|
| |
Instead of replacing writev(2) with loop based on write(2), test system
limit on the number of vectors writev(2) accepts and split call to writev(2)
to several calls in such a way that number of vectors in each call doesn't
exceed this limit (aka UIO_MAXIOV). Bump PORTREVISION.
Notes:
svn path=/head/; revision=49315
|
|
|
FreeBSD's writev(2) implementation is rather unreliable when large number of
vectors is submitted - it returns EINVAL despite the fact that all arguments
are pretty valid. This caused serious problems with GNOME's oaf and prevented
Nautilus from working properly. The problem disappeared when I've replaced
writev(2) call with appropriate loop based around ordinary write(2). Perhaps
this should be investigated and the real source of the problem fixed instead,
but I do not have a time for this right now. For those who interested I'm
ready to provide a step-by step instruction on how to reproduce the bug.
Special thanks to: andersca @ nautilus#irc.gnome.org
Notes:
svn path=/head/; revision=49218
|
