On Sun, Aug 6, 2017 at 2:34 PM, Justus Winter wrote:
> "Brent W. Baccala" writes:
>
> >> Are you aware of the pager rework in [0]? I'm considering to review and
> >> merge these changes. It may make sense to try to come up with a common
> >> API. What is the state of your library, is it a dro
"Brent W. Baccala" writes:
>> Are you aware of the pager rework in [0]? I'm considering to review and
>> merge these changes. It may make sense to try to come up with a common
>> API. What is the state of your library, is it a drop-in replacement?
>>
>> 0: https://git.sceen.net/hurd/hurd.git/l
On Sun, Aug 6, 2017 at 12:40 PM, Justus Winter wrote:
> "Brent W. Baccala" writes:
>
> > but it's obviously got some issues
>
> What kind of issues?
>
I was thinking of a multi-client environment where a disk-backed pager is
also doing non-disk-backed (i.e, cache coherency) operations. One cli
"Brent W. Baccala" writes:
> Hi -
>
> I've learned some interesting things about libpager that I'd like to share
> with the list.
Cool :)
> I've found two bugs in the existing code that were "fixed" by the new
> demuxer that sequentially services requests on each pager object.
>
> For example,
On Tue, Oct 18, 2016 at 01:56:48PM -1000, Brent W. Baccala wrote:
> Can it be done in C? Sure. But following my principle of asking how to
> write the code in the simplest manner, this one is obvious: STL containers
> win.
I'm not saying it can't be done. I'm saying it's not that hard.
--
Rich
On Tue, Oct 18, 2016 at 2:37 AM, Richard Braun wrote:
>
> From my fifteen years or so experience working in various projects with
> C++ and other languages, my opinion is that C++ is never the best
> choice. It makes you trade lines of code for increased complexity in
> understanding and followin
On Mon, Oct 17, 2016 at 09:51:41PM -1000, Brent W. Baccala wrote:
> What do you guys think?
>From my fifteen years or so experience working in various projects with
C++ and other languages, my opinion is that C++ is never the best
choice. It makes you trade lines of code for increased complexity i
Aloha -
I've been thinking more about the data structures involved with the new
libpager code, and they're complex enough that I'd like to write them in
C++11. The pagemap has to contain a list of all clients with copies of a
page, and a queue of clients waiting to access the page. To keep the
m
"Brent W. Baccala" writes:
> Second, I can't find anywhere in the hurd source tree where this function
> is actually used.
Commit 84cf9c0f312637b670cc87224ff7e7c4da659e36 on 2013-09-17
removed the ufs directory, in which the offer_data function used
to call pager_offer_page. The last argument o
Quoting Samuel Thibault (2014-03-25 11:52:43)
> Justus Winter, le Fri 21 Mar 2014 13:57:51 +0100, a écrit :
> > I'm trying to find and fix a deadlock that could very well be in
> > libpager.
>
> When do you get it? What effect does it have: just deadlock a process,
> or the whole pager?
I'm work
Justus Winter, le Fri 21 Mar 2014 13:57:51 +0100, a écrit :
> I'm trying to find and fix a deadlock that could very well be in
> libpager.
When do you get it? What effect does it have: just deadlock a process,
or the whole pager?
We often see "strip" hang, such as in glibc builds, this is really
Quoting Justus Winter (2014-03-21 13:57:51)
> Hi ;)
>
> I'm trying to find and fix a deadlock that could very well be in
> libpager. So I came up with this patch, analogous to
> 901c61a1d25e7c8963e51012760a82730eda1910. I'm not yet sure I found
> "my" deadlock, but not releasing this lock here c
El Thu, 8 Apr 2010 16:15:00 +0200
Samuel Thibault escribió:
> Sergio Lopez, le Thu 08 Apr 2010 16:07:20 +0200, a écrit :
> > In memory_object.defs, m_o_lock_request is defined as
> > simpleroutine, so a call to mach_msg_trap should only enqueue the
> > message and return immediately.
>
> Is this
Sergio Lopez, le Thu 08 Apr 2010 16:07:20 +0200, a écrit :
> Anyway, let's suppose that m_o_lock_request only returns when the
> process has been completed. Then, why do we need an interface to nofity
> its completion (m_o_lock_completed)?
It seems I forgot to mention again that I really have a po
El Thu, 8 Apr 2010 13:55:33 +0200
Samuel Thibault escribió:
> Sergio Lopez, le Thu 08 Apr 2010 13:15:20 +0200, a écrit :
> > > So it's really hung in the kernel. And indeed, even if from
> > > the interface it would seem like it could be asynchronous,
> > > the memory_object_lock_completed() call
Sergio Lopez, le Thu 08 Apr 2010 13:15:20 +0200, a écrit :
> > So it's really hung in the kernel. And indeed, even if from
> > the interface it would seem like it could be asynchronous,
> > the memory_object_lock_completed() call is done from the
> > memory_object_lock_request function itself...
>
El Thu, 8 Apr 2010 00:53:02 +0200
Samuel Thibault escribió:
> HEllo,
>
> Sergio Lopez, le Wed 07 Apr 2010 12:43:15 +0200, a écrit :
> > El Sat, 27 Mar 2010 00:39:19 +0100
> > Samuel Thibault escribió:
> > > From times to times, ext2fs deadlocks on the pager->interlock
> > > mutex. This is an ex
HEllo,
Sergio Lopez, le Wed 07 Apr 2010 12:43:15 +0200, a écrit :
> El Sat, 27 Mar 2010 00:39:19 +0100
> Samuel Thibault escribió:
> > From times to times, ext2fs deadlocks on the pager->interlock mutex.
> > This is an excerpt of what I could find in the process:
> >
> > #2 0x08106e59 in memory
El Sat, 27 Mar 2010 00:39:19 +0100
Samuel Thibault escribió:
> Hello,
>
> From times to times, ext2fs deadlocks on the pager->interlock mutex.
> This is an excerpt of what I could find in the process:
>
> #2 0x08106e59 in memory_object_lock_request ()
> #3 0x0806fdeb in _pager_lock_object (p=
> Looks right to me.
I have checked this change in.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Looks right to me.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
21 matches
Mail list logo
