SF Bug Tracker - ID: 3104527
Submitted: OBATA Akio ( obache ) - 2010-11-07 07:10:28 BRST
In threadutil/inc/ithread.h, it is expected that
PTHREAD_MUTEX_RECURSIVE is defined as macro. But on DragonFly BSD,
it is defined as enum, so not works as expected.
Attachment patch treat that DragonFly BSD always
have PTHREAD_MUTEX_RECURSIVE.
By "Carl Benson" <carl.benson@windriver.com>:
I had to do some modifications myself though, because the Android
build system insists on having a file named "util.h" taking precedence
in its include path, libupnp gets confused because of the same filename
in upnp/src/inc/util.h
When a lot of notifications were generated by a device in a short
period of time then 100% of the CPU was used to reorder those
notifications by pushing back the thread in the job queue. This
mechanism has been modified so now thread sleep 1 ms before being
pushed back into the job queue.
Removing DEFAULT_SCHED_PARAM parameter and use
sched_get_priority_min(DEFAULT_POLICY) instead.
This patch allows a user to customize the stack size of the threads used by
pupnp through the new THREAD_STACK_SIZE variable. This is especially useful
on embedded systems with limited memory where the user can set THREAD_STACK_SIZE
to ITHREAD_STACK_MIN.
However, as this modification can have side effects, I set 0 as the default
value, so threads will continue to use the default stack size of the system
(which varies greatly as stated in
https://computing.llnl.gov/tutorials/pthreads/).
2 - Backport of svn revision 527:
* Added API to ithread, created the following functions:
- int ithread_initialize_library(void);
- int ithread_cleanup_library(void);
- int ithread_initialize_thread(void);
- int ithread_cleanup_thread(void);
* SF Bug Tracker [ 2876374 ] Access Violation when compiling with Visual Studio 2008
Submitted: Stulle ( stulleamgym ) - 2009-10-10 19:05
Hi,
I am one of the devs of the MorphXT project and I use this lib in some
other of my projects, too. When I tried to upgrade the lib earlier for one
of my projects I had to realise that something did not work at first and
while most of the things were reasonably ease to be fixed. Now, the last
thing I encountered was not so easy to fix and I am uncertain if my fix is
any good so I'll just post it here and wait for some comments.
The problem was that I got an Access Violation when calling "UpnpInit". It
would call "ithread_rwlock_init(&GlobalHndRWLock, NULL)" which eventually
led to calling "pthread_cond_init" and I got the error notice at
"EnterCriticalSection (&ptw32_cond_list_lock);". It appeared that
"ptw32_cond_list_lock" was NULL. Now, I found two ways to fix this. Firstly
moving the whole block after at least one of the "ThreadPoolInit" calls
will fix the issue. Secondly, you could add:
#ifdef WIN32
#ifdef PTW32_STATIC_LIB
// to get the following working we need this... is it a good patch or
not... I do not know!
pthread_win32_process_attach_np();
#endif
#endif
right before "ithread_rwlock_init(&GlobalHndRWLock, NULL)".
Just so you know, I am using libupnp 1.6.6 and libpthreads 2.8.0 and both
are linked static into the binaries. I am currently using Visual Studio
2008 for development with Windows being the target OS. Any comment at your
end?
Regards, Stulle
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@529 119443c7-1b9e-41f8-b6fc-b9c35fce742c
libupnp and multi-flows scenario patch
Submited by Carlo Parata from STMicroelectronics.
Hi Roberto and Nektarios,
after an analysis of the problem of libupnp with a multi-flows scenario, I
noticed that the only cause of the freezed system is the ThreadPool
management. There are not mutex problems. In practise, if all threads in the
thread pool are busy executing jobs, a new worker thread should be created if
a job is scheduled (I inspired to tombupnp library). So I solved the problem
with a little patch in threadutil library that you can find attached in this
e-mail. I hope to have helped you.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@515 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By: zephyrus ( zephyrus00jp )
Obs by Marcelo: The issue with linking with -lsocket -lnsl -lrt is not
covered in this changeset beacuse I don't have solaris to test. I will
need some help from zephyrus in this regard. The issue will be addressed
in a future changeset.
Compilation for solaris
I have used gcc3.x and gcc4.x under solaris 10 for x86 / 64 bits.
A couple of Source file fixes were necessary for successful compilation
and runtime behavior.
threadutil/src/ThreadPool.c
POSIX
sched_setschduler() returns non-negative value for success.
Without the fix, UpnpInit() fails immediately.
upnpp/src/api/upnpai.c
There is a typo of a macro name "__sun" in one of the
CPP conditional.
Without the fix, the compilation aborts due to unknown constant
in socket ioctl call.
A few structs and an array is not properly initialized.
Well, I think it may be safe as is, but when I checked it
using purify evaluation version, it was reported that
uninitizlied iszBuffer may cause read of uninitialized memory.
So play it safe.
Configure issue.
This has to be more of a configure magic.
To link a program successfully using network, we need
-lsocket and -lnsl library specifications on the link line.
We also need -lrt for programs that use thread scheduling features.
The sample program under upnp/sample requires
-lsocket -lnsl -lrt
for successful linking.
I added -lsocket -lnsl -lrt to Makefile.in.
configure probably needs to take care of these.
I don't know much about configure, automake, etc., so
I am just raising a flag here.
TIA
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@505 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By: Nick Leverton - leveret
Gnu/KFreeBSD is one of the Debian architectures, it includes a FreeBSD
kernel with GNU userspace (glibc etc). The Gnu/KfreeBSD developers
provided the attached patch to test the appropriate #define and allow pupnp
to build in their environment, and asked me to forward it to you.
Since the test is a simple check for defined(__GLIBC__), this would
presumably also help with other ports of GNU libc to non-Linux kernels.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@458 119443c7-1b9e-41f8-b6fc-b9c35fce742c
[pupnp-devel] NetBSD & Mac OS X packages and patches
Okay, I found a couple more things. I have attached a patch file
against the trunk (version 206) that make the repository code compile
and run on both Mac OS X and NetBSD.
This fixes the following issues:
upnp/src/api/upnpapi.c: SIOCGIFCONF didn't work properly, use
getifaddrs() instead (on BSD systems).
threadutil/src/ThreadPool.c: priorities only work if
_POSIX_PRIORITY_SCHEDULING is defined (and greater than 0).
threadutil/src/LinkedList.c and threadutil/src/iasnprintf.c: use
stdlib.h instead of malloc.h on all BSD systems (not just FreeBSD).
This is important, because malloc.h does not exist on Darwin/Mac OS X.
Cheers
,
Rene
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@207 119443c7-1b9e-41f8-b6fc-b9c35fce742c
defines. These were just aliases, no reason to keep them.
* Changed the comments of the include files that expose the UPnP API
to use only C89 comments and no C99 comments.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@198 119443c7-1b9e-41f8-b6fc-b9c35fce742c
* Enable both device and control point in the same application. Resolve
deadlock in the SSDP processing threads.
* Fix Threadpool expansion condition.
Thanks to Siva Chandran P. for the original patch.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@194 119443c7-1b9e-41f8-b6fc-b9c35fce742c
befor calling va_end().
- Removed all uses of the DBGONLY(x) macro. A static inline empty
function now is used and the compiler takes care of optimizing it out.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@185 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By: Timothy Redaelli - drittz
I made some patches to make it compile under FreeBSD using
gethostbyaddr_r when supported.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@165 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By: Jon Foster - jongfoster
This patch gives basic support for building under Cygwin - it compiles,
links, and a simple UPnP device application can initialise. I'm not sure
if it actually works yet, but this is definitely a step in the right
direction.
Patch is against the 1.4.1 release. Changes are:
* threadutil/inc/ithread.h: Fix the ithread mutex support to use
documented, portable APIs (if present) rather than the Non-Portable (_NP)
ones it uses now. This is required because Cygwin implements only the
portable API.
* threadutil/src/ThreadPool.c: Fake SetPolicyType() to do nothing on Cygwin
because otherwise it fails. Should probably investigate why it fails and
add a proper implementation later.
* upnp/src/api/upnpapi.c: On Cygwin, zero out the GlobalHndMutex structure
before initialising it. Without this, the initialisation fails. This
appears to be a bug in Cygwin.
* upnp/src/genlib/net/uri/uri.c: Use gethostbyname() on Cygwin.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@151 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By:
Fredrik Svensson - svefredrik
Incremented the libray versions and included some comments in the file
configure.ac so that we do not bump the library version excessively,
only the necessary numbers on the next release.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@115 119443c7-1b9e-41f8-b6fc-b9c35fce742c
