oysteikt/mpd
0
0
Fork 0
Code Issues Pull Requests Releases Activity
801c71ed1c
mpd/src/sllist.h

53 lines
1.6 KiB
C
Raw Normal View History

No code change, just add headers git-svn-id: https://svn.musicpd.org/mpd/trunk@4497 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2006-07-31 05:37:34 +02:00
/* the Music Player Daemon (MPD)
The massive copyright update git-svn-id: https://svn.musicpd.org/mpd/trunk@5834 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2007-04-05 05:22:33 +02:00
* Copyright (C) 2003-2007 by Warren Dukes (warren.dukes@gmail.com)
No code change, just add headers git-svn-id: https://svn.musicpd.org/mpd/trunk@4497 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2006-07-31 05:37:34 +02:00
* This project's homepage is: http://www.musicpd.org
*
* 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
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
interface/connection malloc reductions from mpd-ke This patch massively reduces the amount of heap allocations at the interface/command layer. Most commands with minimal output should not allocate memory from the heap at all. Things like repeatedly polling status, currentsong, and volume changes should be faster as a result, and more importantly, not a source of memory fragmentation. These changes should be safe in that there's no way for a remote-client to corrupt memory or otherwise do bad stuff to MPD, but an extra set of eyes to review would be good. Of course there's never any warranty :) No longer do we use FILE * structures in the interface, which means we don't have to allocate any new memory for most connections. Now, before you go on about losing the buffering that FILE * +implies+, remember that myfprintf() never took advantage of any of the stdio buffering features. To reduce the diff and make bugs easier to spot in the diff, I've kept myfprintf in places where we write to files (and not network interfaces). Expect myfprintf to go away entirely soon (we'll use fprintf for writing regular files). git-svn-id: https://svn.musicpd.org/mpd/trunk@4483 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2006-07-30 05:43:38 +02:00
/* a very simple singly-linked-list structure for queues/buffers */
#ifndef SLLIST_H
#define SLLIST_H
clean up CPP includes Try to only include headers which are really needed. We should particularly check all "headers including other headers". The long-term goal is to have a manageable, small API for plugins (decoders, output) without so many mpd internals cluttering the namespace. git-svn-id: https://svn.musicpd.org/mpd/trunk@7319 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:19:26 +02:00
#include "os_compat.h"
interface/connection malloc reductions from mpd-ke This patch massively reduces the amount of heap allocations at the interface/command layer. Most commands with minimal output should not allocate memory from the heap at all. Things like repeatedly polling status, currentsong, and volume changes should be faster as a result, and more importantly, not a source of memory fragmentation. These changes should be safe in that there's no way for a remote-client to corrupt memory or otherwise do bad stuff to MPD, but an extra set of eyes to review would be good. Of course there's never any warranty :) No longer do we use FILE * structures in the interface, which means we don't have to allocate any new memory for most connections. Now, before you go on about losing the buffering that FILE * +implies+, remember that myfprintf() never took advantage of any of the stdio buffering features. To reduce the diff and make bugs easier to spot in the diff, I've kept myfprintf in places where we write to files (and not network interfaces). Expect myfprintf to go away entirely soon (we'll use fprintf for writing regular files). git-svn-id: https://svn.musicpd.org/mpd/trunk@4483 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2006-07-30 05:43:38 +02:00
/* just free the entire structure if it's free-able, the 'data' member
* should _NEVER_ be explicitly freed
*
* there's no free command, iterate through them yourself and just
Replace strdup and {c,re,m}alloc with x* variants to check for OOM errors I'm checking for zero-size allocations and assert()-ing them, so we can more easily get backtraces and debug problems, but we'll also allow -DNDEBUG people to live on the edge if they wish. We do not rely on errno when checking for OOM errors because some implementations of malloc do not set it, and malloc is commonly overridden by userspace wrappers. I've spent some time looking through the source and didn't find any obvious places where we would explicitly allocate 0 bytes, so we shouldn't trip any of those assertions. We also avoid allocating zero bytes because C libraries don't handle this consistently (some return NULL, some not); and it's dangerous either way. git-svn-id: https://svn.musicpd.org/mpd/trunk@4690 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2006-08-26 08:25:57 +02:00
* call free() on it iff you xmalloc'd them */
interface/connection malloc reductions from mpd-ke This patch massively reduces the amount of heap allocations at the interface/command layer. Most commands with minimal output should not allocate memory from the heap at all. Things like repeatedly polling status, currentsong, and volume changes should be faster as a result, and more importantly, not a source of memory fragmentation. These changes should be safe in that there's no way for a remote-client to corrupt memory or otherwise do bad stuff to MPD, but an extra set of eyes to review would be good. Of course there's never any warranty :) No longer do we use FILE * structures in the interface, which means we don't have to allocate any new memory for most connections. Now, before you go on about losing the buffering that FILE * +implies+, remember that myfprintf() never took advantage of any of the stdio buffering features. To reduce the diff and make bugs easier to spot in the diff, I've kept myfprintf in places where we write to files (and not network interfaces). Expect myfprintf to go away entirely soon (we'll use fprintf for writing regular files). git-svn-id: https://svn.musicpd.org/mpd/trunk@4483 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2006-07-30 05:43:38 +02:00
struct strnode {
struct strnode *next;
char *data;
};
struct sllnode {
struct sllnode *next;
void *data;
size_t size;
};
struct strnode *new_strnode(char *s);
struct strnode *new_strnode_dup(char *s, const size_t size);
struct strnode *dup_strlist(struct strnode *old);
struct sllnode *new_sllnode(void *s, const size_t size);
#endif /* SLLIST_H */
Reference in New Issue Copy Permalink