search for: sock_write_byt

Hi, re libshout: MacOSX doesn't have poll(), which prevents sock.c from compiling. I've patched sock.c to use select(), which is supported on MacOSX, and should be elsewhere too. I've marked my changes with "SKoT" comments in the file below. Main changes are in sock_write_bytes(). - SKoT ------8<----- /* sock.c * - General Socket Functions * * Copyright (c) 1999 Jack Moffitt, Barath Raghavan, and Alexander Haväng * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by...

On Friday 17 January 2003 20:17, Karl Heyes shaped the electrons to say: > I would suggest a slightly different approach. > > Instead of increasing the syscall overhead for all sockets, trapping > for uncommon cases. Try the sock_write_bytes and if that is > continuously having to queue (ie not all data can be sent) then display > the warning, maybe make it a run-time option (default enabled). Hi Karl, I will study it later. Do you have commit privileges? If so, I can send you also a patch to solve a memory leak bug (...

...ke once through playlist). karl. -------------- next part -------------- --- libshout/src/shout.c Sun Oct 6 14:22:25 2002 +++ libshout.test/src/shout.c Fri Nov 1 19:58:01 2002 @@ -159,20 +159,24 @@ if (!self) return -1; + self->error = SHOUTERR_SUCCESS; while(remaining) { ret = sock_write_bytes(self->socket, data, remaining); - if(ret < (ssize_t)remaining || errno == EINTR) { - remaining -= (ret>0)?ret:0; - continue; - } - else if(ret < 0) { - self->error = SHOUTERR_SOCKET; - return -1; + if (ret == r...

...ary 2003 06:55, Ricardo Galli wrote: > On Friday 17 January 2003 20:17, Karl Heyes shaped the electrons to say: > > I would suggest a slightly different approach. > > > > Instead of increasing the syscall overhead for all sockets, trapping > > for uncommon cases. Try the sock_write_bytes and if that is > > continuously having to queue (ie not all data can be sent) then display > > the warning, maybe make it a run-time option (default enabled). > > Hi Karl, > I will study it later. Do you have commit privileges? If so, > I can send you also a patch to solv...

...g) /* packet too delayed, discard */ ) { /* almost a no-op */ printf("DEBUG: discarding %d bytes from queue!!! LAG=%d MAXLAG=%d\n", bytes, now - abuf->timestamp, maxlag); } else { printf("DEBUG: sending %d bytes from queue...\n", bytes); sbytes = sock_write_bytes(client->con->sock, abuf->data[client->pos], bytes); <p><p> -- ricardo "I just stopped using Windows and now you tell me to use Mirrors?" - said Aunt Tillie, just before downloading 2.5.3 kernel. --- >8 ---- List archives: http://www.xiph.org/archiv...

On 19/02/02 18:09, Likai Liu shaped the electrons to say: > >It's partially done in the patch I've sent you, completelly done in my > >current version... I can send you the second patch, you will save some > > work. > > how is the calculation being done? do you extract the bitrate from the > stream data, or do you use a different method? I'd advocate *that*

Karl Heyes wrote: > Is it just the java player that seems to be unreliable. There is a > couple > of outstanding bugs in ices for network socket error cases, but the fixes > these are with Mike. I'm not entirely sure. Certainly, playback is flawless with Winamp. Every now and then, Ices seems to just stop, and swallow up all my CPU. I'm not sure if this was caused by my

...ut; + char buffer[8192]; + int status; + size_t count; + + thread_rename("CGI Script Thread"); + fname = req.path + 9; + if (*fname) { + cgioutput = popen(fname, "r"); + if (cgioutput != NULL) { + while ((count = fread(buffer, 1, sizeof(buffer), cgioutput))) { + sock_write_bytes(con->sock, buffer, count); + } + status = pclose(cgioutput); + if (WIFEXITED(status)) { + if (WEXITSTATUS(status)) { + kick_not_connected(con, "CGI Script terminated with an error"); + } else { + kick_not_connected(con, "CGI Script terminated with no e...

...for example, the > > connection id. Wouldn't it be better to use a simple circularly linked list > > : the accesses and insertions would be faster (constant!). Are we wrong ? If > > yes, why ? > > > > ---------------------------------------- > > > > In sock_write_bytes(), there is a "sanity check" which can return > > SOCK_ERROR. If this happens, there can be a problem in the calling function > > because this one will then verify the kind of return using > > sock_recoverable(sock_error()). And sock_error() will return something wrong...