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.
(cherry picked from commit ff006272b5)
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
(hand cherry picked from commit 8e846368e0)
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.
(cherry picked from commit c33b11d09f)
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/).
(cherry picked from commit 467f9987a1)
- 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/trunk@527 119443c7-1b9e-41f8-b6fc-b9c35fce742c
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/trunk@514 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By Luke Kim - nereusuj
Version 1.6.5 cannot be compiled because of some changes in 1.6.3.
MSVC does not support stdint.h, gettimeofday(), sys/param.h, const int
variables in array size and Windows does not define _WINDOWS_ but define
_WINDOWS.
* MSVC does not understand "const int"'s as declarators of array
dimensions, we must use #define'd constants.
* Use WIN32 instead of _WINDOWS_ or _WINDOWS.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@331 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
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
