|
|
Mozy Online Backup: 2GB Free. Automatic. Secure.
Subject: RE: suggested threadlib simplification - msg#00032
List: lib.openal.devel
> -----Original Message-----
> From: openal-devel-bounces@xxxxxxxxxxxxxxxxxxxxxxx
> [mailto:openal-devel-bounces@xxxxxxxxxxxxxxxxxxxxxxx] On
> Behalf Of Prakash Punnoor
> Sent: Samstag, 28. Oktober 2006 12:32
> To: openal-devel@xxxxxxxxxxxxxxxxxxxxxxx
> Subject: [Openal-devel] suggested threadlib simplification
>
> Hi,
>
> is following OK? This simplifies code and gets rid of a
> compiler warning:
>
> Index: src/al_threadlib.c
> [...]
This looks OK, I can't think of a reason why pthread_exit should be
necessary after the mixer thread has finished its work. Patch applied.
Cheers,
S.
Was this page helpful?
Thread at a glance:
Previous Message by Date:
click to view message preview
Code in headers
Just a small remark about code in C headers: I've just seen that some
code has been moved from *.c files to *.h files, and I will revert those
changes and any similar ones in the future. There are tons of reasons to
separate interfaces from implementations and apart from performance no
reason for merging them. We can discuss on a case-by-case basis if code
should really go into headers, but only based on measurements and very
rarely.
Cheers,
S.
Next Message by Date:
click to view message preview
RE: AL_SIZE returns buffer size / Channels on linux
> -----Original Message-----
> From: openal-devel-bounces@xxxxxxxxxxxxxxxxxxxxxxx
> [mailto:openal-devel-bounces@xxxxxxxxxxxxxxxxxxxxxxx] On
> Behalf Of Nathan Ford
> Sent: Freitag, 13. Oktober 2006 20:53
> To: Openal-devel@xxxxxxxxxxxxxxxxxxxxxxx
> Subject: [Openal-devel] AL_SIZE returns buffer size /
> Channels on linux
> [...]
> Unless i've missed something it seems the rest of the
> interactions with ->size are in bytes. Should the size not be
> divided by the number of channels, or should the AL_SIZE
> return multiply by the number of channels in order to
> correctly return the number of bytes.
> [...]
FYI: I've fixed the AL_SIZE query by multiplying with the number of
channels again, this seems to be the best fix.
Cheers,
S.
Previous Message by Thread:
click to view message preview
suggested threadlib simplification
Hi,
is following OK? This simplifies code and gets rid of a compiler warning:
Index: src/al_threadlib.c
===================================================================
--- src/al_threadlib.c (Revision 1394)
+++ src/al_threadlib.c (Arbeitskopie)
@@ -10,20 +10,6 @@
#if defined(USE_POSIXTHREADING)
-typedef int ( *ptfunc ) ( void * );
-
-static void *runThread( void *data ) AL_ATTRIBUTE_NORETURN_;
-
-static void *runThread( void *data )
-{
- ptfunc fn = ( ptfunc ) data;
- fn( NULL );
- pthread_exit( NULL );
-#ifndef HAVE___ATTRIBUTE__
- return NULL;
-#endif
-}
-
ThreadID _alCreateThread( int ( *fn ) ( void * ) )
{
pthread_attr_t type;
@@ -39,7 +25,7 @@
pthread_attr_setdetachstate( &type, PTHREAD_CREATE_JOINABLE );
- if( pthread_create( thread, &type, runThread, ( void * ) fn ) != 0 ) {
+ if( pthread_create( thread, &type, (void* (*) ( void * ))fn, NULL ) !=
0 ) {
free( thread );
return NULL;
}
--
(Â= =Â)
//\ Prakash Punnoor /\\
V_/ \_V
pgpo1XYPCJ1N6.pgp
Description: PGP signature
_______________________________________________
Openal-devel mailing list
Openal-devel@xxxxxxxxxxxxxxxxxxxxxxx
http://opensource.creative.com/mailman/listinfo/openal-devel
Next Message by Thread:
click to view message preview
Code in headers
Just a small remark about code in C headers: I've just seen that some
code has been moved from *.c files to *.h files, and I will revert those
changes and any similar ones in the future. There are tons of reasons to
separate interfaces from implementations and apart from performance no
reason for merging them. We can discuss on a case-by-case basis if code
should really go into headers, but only based on measurements and very
rarely.
Cheers,
S.
|
|