Re: libdispatch don't build on 8.2-RELEASE amd64
Worked with GCC, but support blocks is disabled... :( On 2/27/11 1:42 AM, Danilo Egea wrote: Hi guys, Anyone know what's going on? PS: with clang-devel libtool: compile: clang -DHAVE_CONFIG_H -I. -I../config -I.. -I.. -fPIC -MT time.lo -MD -MP -MF .deps/time.Tpo -c shims/time.c -fPIC -DPIC -o .libs/time.o libtool: compile: clang -DHAVE_CONFIG_H -I. -I../config -I.. -I.. -fPIC -MT time.lo -MD -MP -MF .deps/time.Tpo -c shims/time.c -o time.o >/dev/null 2>&1 mv -f .deps/time.Tpo .deps/time.Plo /bin/sh ../libtool --tag=CC--mode=link clang -fPIC-o libshims.la mach.lo time.lo -lpthread -L/usr/local/lib -lBlocksRuntime libtool: link: ar cru .libs/libshims.a .libs/mach.o .libs/time.o libtool: link: ranlib .libs/libshims.a libtool: link: ( cd ".libs" && rm -f "libshims.la" && ln -s "../libshims.la" "libshims.la" ) /bin/sh ../libtool --tag=CC--mode=link clang -Wall -fblocks -fPIC -o libdispatch.la -rpath /usr/local/lib libdispatch_la-apply.lo libdispatch_la-benchmark.lo libdispatch_la-object.lo libdispatch_la-once.lo libdispatch_la-queue.lo libdispatch_la-queue_kevent.lo libdispatch_la-semaphore.lo libdispatch_la-source.lo libdispatch_la-source_kevent.lo libdispatch_la-time.lo libshims.la -lpthread -L/usr/local/lib -lBlocksRuntime libtool: link: clang -shared .libs/libdispatch_la-apply.o .libs/libdispatch_la-benchmark.o .libs/libdispatch_la-object.o .libs/libdispatch_la-once.o .libs/libdispatch_la-queue.o .libs/libdispatch_la-queue_kevent.o .libs/libdispatch_la-semaphore.o .libs/libdispatch_la-source.o .libs/libdispatch_la-source_kevent.o .libs/libdispatch_la-time.o -Wl,--whole-archive ./.libs/libshims.a -Wl,--no-whole-archive -L/usr/local/lib -lpthread -lBlocksRuntime -Wl,-soname -Wl,libdispatch.so.0 -o .libs/libdispatch.so.0 /usr/local/bin/ld: .libs/libdispatch_la-apply.o: relocation R_X86_64_PC32 against symbol `_dispatch_hw_config' can not be used when making a shared object; recompile with -fPIC /usr/local/bin/ld: final link failed: Bad value clang: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop in /usr/ports/devel/libdispatch/work/libdispatch-r174/src. *** Error code 1 Stop in /usr/ports/devel/libdispatch/work/libdispatch-r174/src. *** Error code 1 Stop in /usr/ports/devel/libdispatch/work/libdispatch-r174. *** Error code 1 Stop in /usr/ports/devel/libdispatch. *** Error code 1 Stop in /usr/ports/devel/libdispatch. -- Danilo Egêa Gondolfo http://daniloegea.wordpress.com __ Fale com seus amigos de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Is pthread_cond_signal(3) man page correct?
On FreeBSD-8.1 this page says: The pthread_cond_signal() function unblocks one thread waiting for the condition variable cond. On Linux it says: The /pthread_cond_signal/() function shall unblock at least one of the threads that are blocked on the specified condition variable /cond/ (if any threads are blocked on /cond/). Also HP page (http://docs.hp.com/en/B2355-90130/pthread_cond_signal.3T.html) says: "If there are no threads blocked on /cond/, this function has no effect." And later it says: "It is possible that more than one thread can be unblocked due to a spurious wakeup." This is quite confusing: in case nobody is waiting does it block or not? In case other threads are waiting it's really "any arbitrary number of threads are woken up"? Or on FreeBSD it's strictly 1? Shouldn't this be defined in one and only way by POSIX and all POSIX-compliant systems should work exactly the same. I think man page should be expanded to give more comprehensive explanation. Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is pthread_cond_signal(3) man page correct?
Forwarding to standards@ and davidxu@ per Garrett Cooper suggestion. Also I want to add that I came to this question while observing behavior consistent with multiple wakeup on FreeBSD-8.1. The heavily multi-threaded code that assumes that only one thread can be woken up by one pthread_cond_signal call crashes, and the only reasonable explanation so far is that more than one threads are actually being woken up. Yuri On 02/27/2011 12:54, Yuri wrote: On FreeBSD-8.1 this page says: The pthread_cond_signal() function unblocks one thread waiting for the condition variable cond. On Linux it says: The /pthread_cond_signal/() function shall unblock at least one of the threads that are blocked on the specified condition variable /cond/ (if any threads are blocked on /cond/). Also HP page (http://docs.hp.com/en/B2355-90130/pthread_cond_signal.3T.html) says: "If there are no threads blocked on /cond/, this function has no effect." And later it says: "It is possible that more than one thread can be unblocked due to a spurious wakeup." This is quite confusing: in case nobody is waiting does it block or not? In case other threads are waiting it's really "any arbitrary number of threads are woken up"? Or on FreeBSD it's strictly 1? Shouldn't this be defined in one and only way by POSIX and all POSIX-compliant systems should work exactly the same. I think man page should be expanded to give more comprehensive explanation. Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: seeking into /dev/{null,zero}
On Wed Feb 23 11, Garrett Cooper wrote:
> On Wed, Feb 23, 2011 at 3:53 PM, Alexander Best wrote:
> > On Wed Feb 23 11, Garrett Cooper wrote:
> >> On Feb 22, 2011, at 9:51 AM, John Baldwin wrote:
> >>
> >> > On Tuesday, February 22, 2011 11:46:05 am Garrett Cooper wrote:
> >> >> (Please bottom post)
> >> >>
> >> >> On Tue, Feb 22, 2011 at 8:31 AM, Andrew Duane
> >> >> wrote:
> >> >>> I thought seeking past EOF was valid; writing something creates a file
> >> > with a hole in it. I always assumed that was standard semantics.
> >> >>
> >> >> That's with SET_HOLE/SET_DATA though, correct? If so, outside of
> >> >> that functionality I would assume relatively standard POSIX semantics.
> >> >
> >> > Err, no, you can always seek past EOF and then call write(2) to extend a
> >> > file
> >> > (it does an implicit ftruncate(2)). SEEK_HOLE and SEEK_DATA are
> >> > different,
> >> > they are just used to discover sparse regions within a file.
> >
> > on the other hand POSIX says:
> >
> > "The behavior of lseek() on devices which are incapable of seeking is
> > implementation-defined.
> > The value of the file offset associated with such a device is undefined."
> >
> > ...if we define /dev/{zero,null} as incapable of seeking the current
> > implementation should be ok.
> >
> >> >
> >> > From the manpage:
> >> >
> >> > The lseek() system call allows the file offset to be set beyond the
> >> > end
> >> > of the existing end-of-file of the file. If data is later written at
> >> > this point, subsequent reads of the data in the gap return bytes of
> >> > zeros
> >> > (until data is actually written into the gap).
> >>
> >> You're correct. Linux (Fedora 13) isn't POSIX compliant (this is
> >> from the official POSIX text):
> >>
> >> The lseek ( ) function shall allow the file offset to be set beyond the
> >> end of the existing data in the file. If data is later written at this
> >> point, subsequent reads of data in the gap shall return bytes with the
> >> value 0 until data is actually written into the gap.
>
> Yes, but look at how it's defined by POSIX before you do that
> (yes, there's a section for null/zero IIRC).
i cannot find any references to null/zero in connection with seeking in the
POSIX specs.
> Thanks,
> -Garrett
--
a13x
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is pthread_cond_signal(3) man page correct?
On 2011/02/28 05:26, Yuri wrote: > Forwarding to standards@ and davidxu@ per Garrett Cooper suggestion. > > Also I want to add that I came to this question while observing behavior > consistent with multiple wakeup on FreeBSD-8.1. The heavily > multi-threaded code that assumes that only one thread can be woken up by > one pthread_cond_signal call crashes, and the only reasonable > explanation so far is that more than one threads are actually being > woken up. > > Yuri > > > On 02/27/2011 12:54, Yuri wrote: >> On FreeBSD-8.1 this page says: >> The pthread_cond_signal() function unblocks one thread waiting for the >> condition variable cond. >> >> On Linux it says: >> The /pthread_cond_signal/() function shall unblock at least one of the >> threads that are blocked on the specified condition variable /cond/ >> (if any threads are blocked on /cond/). >> >> Also HP page >> (http://docs.hp.com/en/B2355-90130/pthread_cond_signal.3T.html) says: >> "If there are no threads blocked on /cond/, this function has no >> effect." And later it says: "It is possible that more than one thread >> can be unblocked due to a spurious wakeup." >> >> This is quite confusing: in case nobody is waiting does it block or >> not? In case other threads are waiting it's really "any arbitrary >> number of threads are woken up"? Or on FreeBSD it's strictly 1? >> Shouldn't this be defined in one and only way by POSIX and all >> POSIX-compliant systems should work exactly the same. >> >> I think man page should be expanded to give more comprehensive >> explanation. >> >> Yuri >> ___ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "freebsd-hackers-unsubscr...@freebsd.org" >> It is really not important if pthread_cond_signal wake up one thread or multiple threads in corner case, because POSIX said: --- When using condition variables there is always a Boolean predicate involving shared variables associated with each condition wait that is true if the thread should proceed. Spurious wakeups from the pthread_cond_timedwait() or pthread_cond_wait() functions may occur. Since the return from pthread_cond_timedwait() or pthread_cond_wait() does not imply anything about the value of this predicate, the predicate should be re-evaluated upon such return. --- I think in normal case, pthread_cond_signal will wake up one thread, but other events for example, UNIX signal and fork() may interrupt a thread sleeping in kernel, and cause pthread_cond_wait to return to userland, this is called spurious wakeup, and other events, I can not think of yet, but I believe they exist. Regards, David Xu ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is pthread_cond_signal(3) man page correct?
On Feb 27, 2011, at 4:26 PM, Yuri wrote: > Forwarding to standards@ and davidxu@ per Garrett Cooper suggestion. > > Also I want to add that I came to this question while observing behavior > consistent with multiple wakeup on FreeBSD-8.1. The heavily multi-threaded > code that assumes that only one thread can be woken up by one > pthread_cond_signal call crashes, and the only reasonable explanation so far > is that more than one threads are actually being woken up. It depends on what you mean by wakeup. More than one thread may unblock, but only one thread will have the mutex locked after wakeup. If other threads awake (as allowed by POSIX), they will have to check the state protected by the mutex to see if they really should awake and continue or if they should block again on the CV. A wakeup from pthread_cond_wait() should not assume that he was the only thread awoken. -- DE___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is pthread_cond_signal(3) man page correct?
On Sunday 27 February 2011 22:26:18 Yuri wrote:
> Also I want to add that I came to this question while observing behavior
> consistent with multiple wakeup on FreeBSD-8.1. The heavily
> multi-threaded code that assumes that only one thread can be woken up by
> one pthread_cond_signal call crashes, and the only reasonable
> explanation so far is that more than one threads are actually being
> woken up.
pthread_cond_signal() can indeed wake up more than one thread. That's why you
should always wrap pthread_cond_wait() in a loop. For example a blocking
queue could be implemented like this (pseudo code):
take() {
pthread_mutex_lock(mutex);
while(queue->empty()) {
pthread_cond_wait(cond, mutex);
}
item = queue->get();
pthread_mutex_unlock(mutex);
return item;
}
put(item) {
pthread_mutex_lock(mutex);
queue->put(item);
pthread_cond_signal(cond);
pthread_mutex_unlock(mutex);
}
pthread_cond_signal() itself never blocks.
Hope this helps.
--
Pieter de Goeje
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
