l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On PATH_MAX


From: Bas Wijnen
Subject: Re: On PATH_MAX
Date: Tue, 8 Nov 2005 18:16:49 +0100
User-agent: Mutt/1.5.11

On Tue, Nov 08, 2005 at 10:04:50AM -0700, Christopher Nelson wrote:
> > > What mechanism allows it to map *parts* of a single transfer in?
> > 
> > There is no transfer of data, there is only transfer of the 
> > container capability.  This capability gives access to a set 
> > of pages, which can be mapped in or out of the address space 
> > when the process likes.
> 
> You still have data transfer, even if it's only in the form of metadata.
> A thread can't access any memory until it's mapped into its address
> space.  If you say that a thread must only keep a handle to the metadata
> that defines the memory and then map it in and out as needed, you
> essentially turn the operation into an open..read..close, and you add
> tremendous complexity in the form of a buffering layer to map pages in
> and out.  I'm not saying its impossible, I'm saying its not a good idea,
> IMHO.

Of course _if_ it's done, then it should only be done for long transfers.
That is, if the majority of transfers will be short (say less than the page
size), then direct transfers should be accepted.  But there must be a limit to
their size.  Larger objects can be transferred using containers.  It is no
problem if there is lower performance in that case, as long as it doesn't hurt
the normal (little data) case.  I didn't think it through well enough to see
if it would, but I think the cost would not be much.  However, the complexity
alone may be a reason not to want it.  However, removing arbitrary limits is a
good idea in general IMO.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]