Peter Seebach wrote:
...
> Imagine a word processor with this behavior. No attempt to save your
> file, no nothing, it just suddenly closes all windows and dies.
I think most people can think of at least one widely used commerical
word processor with exactly this behaviour. :-)
To Unsubscribe:
Dan Kegel wrote:
...
> Don't jump to conclusions. He's honestly trying to
> understand what the optimal interface would be.
> Let him catch up. Help him understand the requirements
> which motivated the kqueue design and why his proposed
> system call does not meet them.
>
> His role right now
John Polstra wrote:
>
> In article <[EMAIL PROTECTED]>, Jonas Bulow
> <[EMAIL PROTECTED]> wrote:
> > John Polstra wrote:
> Actually I thought about this some more, and I'm not all that sure
> it's possible. I haven't actually _tried_ it, but
I'm trying to build a preforked and threaded server. When it comes to
the threading part it seems that non-preemtive threads have a lot of
benefits if the server is a statefull-server.
What I'm trying to say is that the server is not going to do a lot of
computation for each request. The server
John Polstra wrote:
> Jonas Bulow wrote
> > Maybe I havn't been thinking enough but wouldn't this lock mechanism
> > be a good choice to use for mmaped:memory accessed by multiple
> > processes?
>
> It depends on the amount of contention you expect. The co
Wes Peters wrote:
>
> Jonas Bulow wrote:
> >
> > Ronald G Minnich wrote:
> > >
> > > I don't know about the "bsd" or whatever way. If you're doing real
> > > parallel programming and want real performance, you'll use a test-an
John Polstra wrote:
> If you want the "BSD way" you should probably create a 0-length
> temporary file somewhere and use the flock(2) system call on it. The
> file itself isn't important; it's just something to lock.
I don't see any reason to do system calls just because I want to do an
atomic o
Ronald G Minnich wrote:
> On Fri, 11 Aug 2000, John Polstra wrote:
> > In article <[EMAIL PROTECTED]>,
> > Jonas Bulow <[EMAIL PROTECTED]> wrote:
> > > Jonas Bulow wrote:
> > > >
> > > > What is the "BSD-way" of access to shar
Jonas Bulow wrote:
>
> What is the "BSD-way" of access to shared memory (mmap:ed) secure (avoid
> race conditions, etc)? Right now I'm using posix semaphores but I would
> like to know if there is a substitute like the way kqueue is for
> select/poll.
Hmm, I thi
What is the "BSD-way" of access to shared memory (mmap:ed) secure (avoid
race conditions, etc)? Right now I'm using posix semaphores but I would
like to know if there is a substitute like the way kqueue is for
select/poll.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-
Alfred Perlstein wrote:
> Yes. :) When FreeBSD gets scheduler activations you'll be able to change
> to a single threaded process that will have excellent performance, the
> scheduler activations are just around the corner.
Can you explain what scheduler activations are?
To Unsubscribe: send m
Hi,
How does the UVM system compare to the VM system in FreeBSD? Are there
any benchmark tests or research results in this area?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
12 matches
Mail list logo
