tem);
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, s
On Monday 28 February 2011 16:08:32 Yuri wrote:
> On 28.02.11 2:41, Pieter de Goeje wrote:
> > 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
>
> > q
00444.html
Check out this code from FreeBSD's OpenJDK6 port:
#if __FreeBSD_version > 900030
return pthread_getthreadid_np();
#else
long tid;
thr_self(&tid);
return (pid_t)tid;
#endif
The underlying type of a tid (lwpid_t in kernel) is
On Tuesday 16 August 2011 14:09:32 Matt Burke wrote:
> I'm trying to setup a box to do automated FreeBSD builds for other hosts
> from multiple source trees.
>
> I have a couple of source trees mounted - for legibility's sake let's say
> /build/stable and /build/current. I also have a few obj dirs
On Friday, August 19, 2011 12:15:30 PM Tom Evans wrote:
> On Thu, Aug 18, 2011 at 6:50 PM, Yuri wrote:
> > Some latest hard drives have logical sectors of 512 byte when they
> > actually have 4k physical sectors. Here is the document describing what
> > to do in such case:
> > http://ivoras.net/bl
On Thursday 14 June 2012 06:48:14 Wojciech Puchar wrote:
> >> file to take 900MB or... can i call some system function to "punch"
> >> holes?
> >
> > I think you can only truncate the file at this time, pretty much like
> > brk() works for memory.
>
> BAD. suppose i keep windoze VM image on files
d.com/developer/
In particular (recording and playback with low latency):
http://manuals.opensound.com/developer/fulldup.c.htm
Barring implementation differences, this should all apply to FreeBSD.
To get really low delays you should probably adjust the hw.snd.latency
sysctls.
Regards,
Pieter de
FreeBSD/i386)
I would be grateful if someone could shed some light on this.
Regards,
Pieter de Goeje
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
n why it won't work.
- Pieter de Goeje
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On zaterdag 31 maart 2007, Garrett Cooper wrote:
> Pieter de Goeje wrote:
> > Hello List,
> >
> > I have these files:
> > --- loader.cpp ---
> > #include
> > #include "tls.h"
> >
> > int main() {
> > tls = 0;
> >
wrote:
> family = (family == AF_INET) ? AF_UNSPEC :
> AF_INET6; break;
> +
> + case '8':
> + utf8_mode = 1;
Add missing break statement here?
>
> case 'a':
>
On Tuesday 17 April 2007, Andre Oppermann wrote:
> Zhang Weiwu wrote:
> > On Tue, 2007-04-17 at 10:37 +0300, Nikos Vassiliadis wrote:
> >>On Monday 16 April 2007 21:24, Zhang Weiwu wrote:
> >>>Pieter de Goeje 写道:
> >>>>I think your patch looks
ds
> Manolito
>
> please
> CC mail me. i'm not Subscribed to the list
ki_ppid (parent process id) will be zero.
Cheers,
Pieter de Goeje
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ha
for Linux programs only work on i386 or -current amd64, so either
downgrade to 32bits FreeBSD or upgrade to FreeBSD 7, or find a version of the
program that doesn't use TLS (non threaded version).
Hope this helps,
Pieter de Goeje
___
freebsd-hacke
On Wednesday 22 August 2007, Roman Divacky wrote:
> On Wed, Aug 22, 2007 at 01:36:20AM +0200, Pieter de Goeje wrote:
> > On Tuesday 21 August 2007, sam wrote:
> > > Hi, all.
> > >
> > > i am try runing Enemy Territory: Quake Wars server
> > > (links on
On Monday 24 September 2007, sam wrote:
> Hi
>
> # su hlds -c "ktrace -i ./hlds_run -game cstrike +ip 0.0.0.0 +port 27015
> +map de_dust -debug"
> Auto detecting CPU
> Using Pentium II Optimised binary.
> Enabling debug mode
> Auto-restarting the server on crash
>
> Console initialized.
> scandir f
hing together just for testing then.
>
>
>
> Adrian
How about:
cd /boot/kernel; ls *.ko | sed 's/\.ko/_load="YES"/'
I think you still want to remove some modules by hand, for example snd_driver.
--
Pieter de Goeje
__
> $ asdf: command not found
> cought broken pipe
> i: 1 could only wrote -1 bytes. total wrote: 5120
>
> $ ./a.out |asdf
> $ asdf: command not found
> cought broken pipe
> i: 12 could only wrote -1 bytes. total wrote: 61440
>
> $ ./
memory.
TCP provides very good throughput, and it achieves this using large send and
receive buffers. Your userspace implementation will need to implement
something similar. A few hundred bytes per connection is simply not enough.
If you want to deal wit
On Monday 12 July 2010 22:25:25 Sergey Babkin wrote:
> Pieter de Goeje wrote:
> > On Saturday 10 July 2010 14:05:29 Sergey Babkin wrote:
> > > Hi guys,
> > >
> > > I've got this idea, and I wonder if anyone has done it already,
> > > and if not t
dge up that name.
> >
> > man 2 select
>
> If the fd is a socket then you can also use setsockopt(2) to set
> SO_RCVTIMEO and check for EWOULDBLOCK (same as EAGAIN) upon read(2) or
> recv(2) errors. The net effect is the same of using select but the
> syntax is simpler, IMO.
s several lines in length)
>
> Thanks,
> -ip
Perhaps you mean lockf(3) ?
--
Pieter de Goeje
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
goes from
> 230-270 MB/s to only 13 MB/s
I noticed lately that the blocksize and fragment size can make a huge
difference on filesystem performance when dealing with big files. Performance
went up from 130MB/s to 200MB/s (2 disk raid0), after I added the following
parameters to newfs(8): -b 65536 -f 8192. This increases the block and
fragment size by a factor of 4 over the the defaults.
Also, you use dd with a small blocksize. Try 64k or 128k instead.
- 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"
nd has no knowledge whatsoever of the filesystems
on top of it.
--
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"
at of ACPI-fast.
Regards,
Pieter de Goeje
- 8< - clock_gettime.c - 8< --
#include
#include
#include
#define COUNT 100
int main() {
struct timespec ts_start, ts_stop, ts_read;
double time;
int i;
clock_gettime(CLOCK_MONOTONIC
libgomp uses it's own implementation of POSIX semaphores (using
phtread mutexes) instead of FreeBSD's sem(4). If the program below is run
against FreeBSD's implementation, it quickly stops growing because there is a
limit on the number of allocated semaphores.
It would be
On Wednesday 06 January 2010 22:49:44 shrivatsan wrote:
> Hi,
>
> I have configured a malloc-backed memory disk, and I mount the device on to
> the file system. I write some data onto the file system. I see that the
> free memory indicated by kmem_map_free goes down, and this is proportional
> to t
o_work(&w);
}
And a provider does this:
pthread_mutex_lock(&m);
add_work(&w);
pthread_cond_signal(&c);
pthread_mutex_unlock(&m);
- Pieter de Goeje
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinf
On Monday 15 March 2010 04:33:04 Havacci wrote:
> How I can drop cache memory of my FreeBSD ? I search a lot about this
> and don't find anything.
> In Linux i usualy use this command:
> sync; echo 3 > /proc/sys/vm/drop_caches
Something comparable can be achieved by unmounting and remounting the t
On Friday 23 April 2010 17:40:12 Joerg Sonnenberger wrote:
> On Fri, Apr 23, 2010 at 06:18:46PM +0300, Eitan Adler wrote:
> > > - use a matrix is faster than use a linked list?
> >
> > For what?
> > For insertion and deletion no - linked list is faster. For sequential
> > access they are the same s
gt;> more refined than the others - thanks for all the hints everyone!
> >>
> >>
> >> http://www.googlebit.com/freebsd/patches/rc_fancy.patch-5
> >
> > Looks like this version does something strange - from an xterm, the
> > spacing is correct, but from console, it doesn't do anything with the
> > \033[71G in the echo. I've played with term types, but can't seem to
> > make it act the same under console as it does in an xterm.
> >
> > Anyone know the issue?
>
> Thanks to Rick Petty for pointing me in the right direction (man page!),
> here's the latest, and I think solid patch (for RELENG-6):
>
>
> http://www.googlebit.com/freebsd/patches/rc_fancy.patch-6
>
>
> Eric
Looks really good to me :)
Regards,
Pieter de Goeje
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
unction can set
> errno to EISDIR and yet that's what's happening here.
>
I did some research on it, and it seems the mkdir utility is aware of the
EISDIR error. Kinda weird if you ask me, since it isn't documented.
Pieter de Goeje
_
Hi Chris,
On Sunday 11 June 2006 07:51, Chris Jones wrote:
> Hi, folks --- as some of you might know, FreeBSD has a Summer of Code
> project to bring resource limits to jails, and one part of that is to
> permit an administrator to put limits on a jail's CPU usage. That's
> where I come in: I'm t
but has to wait on the harddisk. The
buildworld 'benchmark' is probably for a large part I/O bound.
- Pieter de Goeje
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Thursday 14 September 2006 19:28, Gary Corcoran wrote:
> The confusing thing is that I thought 'real' time should be >= 'user' +
> 'sys'. But here 'user' is much greater than 'real' for both machines! The
> sense I got from the other messages in this thread is that 'user' time is
> somewhat mea
On Thursday 12 October 2006 17:24, Oliver Fromme wrote:
> Interestingly, in both tests the compressed size of the
> "gzip" case was slightly larger than the "tar cz" case.
> That's the opposite of what I got in my very first test
> (when archiving the root file system).
I also found that the diffe
er you created the thread is an easy way
to create an "uncontrolled" thread. Effectively the same as #3. The thread
will cleanup automatically after the thread function returns.
-- Pieter de Goeje
___
freebsd-hackers@freebsd.org mailing list
http
On Tuesday 28 November 2006 23:41, Garrett Cooper wrote:
> So that means no, after a function's definition is reached the
> thread/resources stay in a semi-'alive' (maybe 'zombified') state?, or
> does the kernel cleanup / reclaim all of the resources tied up with the
> thread?
> -Garrett
If you de
38 matches
Mail list logo
