On Thu, Sep 1, 2016 at 2:16 PM, Richard Braun wrote:
>
> Therefore I'm going back to the idea of using a thread pool. If a
> mach_msg call succeeds, good for you, grab the next message. If not,
> at least you're not affecting other users, except maybe through a
> denial of service, the only kind
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
