On Thu, Sep 01, 2016 at 01:34:43PM -1000, Brent W. Baccala wrote:
> What happened with select? mach_msg() returned prematurely? I can handle
> that fine. In this case, mach_msg() isn't returning at all.
You're missing the point. The point is vm_map has no timeout. In
addition, the fact that the
On Thu, Sep 1, 2016 at 1:18 PM, Richard Braun wrote:
> On Thu, Sep 01, 2016 at 01:02:18PM -1000, Brent W. Baccala wrote:
>
> > I want a non-blocking send. This one blocks if the message is vm_map,
> the
> > memory object passed in is goofed, and the message is targeted at a task
> > port on the
On Fri, Sep 02, 2016 at 01:18:26AM +0200, Richard Braun wrote:
> In my opinion, your network server should do what all servers do,
> i.e. dedicate a thread to the processing of a complete RPC and spawn
> as many as necessary when receiving messages.
At least for RPCs. Is there a way you can detec
On Thu, Sep 01, 2016 at 01:02:18PM -1000, Brent W. Baccala wrote:
> Here's the call:
>
> mach_msg(msg, MACH_SEND_MSG | MACH_SEND_TIMEOUT, msg->msgh_size,
> 0, msg->msgh_remote_port,
> 0, MACH_PORT_NULL);
>
> Why should I specify MACH_RCV_TIMEOUT? It's not a recei
On Thu, Sep 1, 2016 at 12:38 PM, Richard Braun wrote:
> > > Most modern microkernels use synchronous IPC
> > > that just block, and many operations on top of them do block. The
> > > overall system on the other hand must be careful to avoid such
> > > deadlocks.
> >
> > OK, I read the Mach docume
On Thu, Sep 01, 2016 at 11:54:20AM -1000, Brent W. Baccala wrote:
> On Thu, Sep 1, 2016 at 10:28 AM, Richard Braun wrote:
> > I completely disagree.
>
> Thank you, Richard. Really! Thank you for disagreeing. Now we can have a
> good discussion about this!
This is how it works. People have opi
On Thu, Sep 1, 2016 at 10:28 AM, Richard Braun wrote:
>
> I completely disagree.
Thank you, Richard. Really! Thank you for disagreeing. Now we can have a
good discussion about this!
> Most modern microkernels use synchronous IPC
> that just block, and many operations on top of them do bloc
On Thu, Sep 01, 2016 at 09:58:00AM -1000, Brent W. Baccala wrote:
> The big problem, as I see it, is that mach_msg() is blocking, and that
> hangs my entire thread. It seems to me that these low-level RPC operations
> like vm_map can't block, otherwise it would defeat the purpose of
> MACH_SEND_TI
Aloha -
I've run into a real kernel-level problem with 'netmsg'.
It's related to the libpager issue. The problem arises when a process gets
an unworkable memory object and tries to vm_map it. This causes the
mach_msg() that sent the vm_map to block indefinitely, even though I've
specified MACH_
Svante Signell, on Thu 01 Sep 2016 12:44:04 +0200, wrote:
> On Wed, 2016-08-31 at 14:16 +0200, Samuel Thibault wrote:
> > Svante Signell, on Wed 31 Aug 2016 14:10:22 +0200, wrote:
> > >
> > >
> > > I would expect values [-20,19] to be OK converted to [5,44] with
> > > #define NICE_TO_MACH_PRIORIT
On Wed, 2016-08-31 at 14:16 +0200, Samuel Thibault wrote:
> Svante Signell, on Wed 31 Aug 2016 14:10:22 +0200, wrote:
> >
> >
> > I would expect values [-20,19] to be OK converted to [5,44] with
> > #define NICE_TO_MACH_PRIORITY(nice) ((nice) + 25) from hurd/hurd/resource.h
> > and
> > #define i
11 matches
Mail list logo
