[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.remoting

Re: Remoting Event problem.

Ken Kolda

9/22/2004 7:11:00 PM

I believe the simplest solution is to mark the client's event handler
function with the [OneWay] attribute. I've never used this technique but
it's described in this article:

http://msdn.microsoft.com/library/en-us/dnpag/html/scalenetc...

Another method is to use the ThreadPool to invoke the events handlers, but
that means you need to take direct control over invoking the event handlers
by calling GetInvocationList() on the event object. This is also a bit risky
since hung clients could cause your thread pool to fill up with hung
threads. You could do your own threading instead so you could interrupt hung
threads after a certain timeout, but now it's getting complicated.

One thing I would definitely recommend is that your client, upon receiving
the event, spawn a new thread (or use the ThreadPool) to execute the code
that actual processes the event. This would greatly reduce the risk of your
server hanging, although it's not failsafe since you've left it in the hands
of the client to be responsible.

Ken


"Joshua Belden" <JoshuaBelden@discussions.microsoft.com> wrote in message
news:3783E15F-C9D3-49CA-95B7-B6C0F8E052E9@microsoft.com...
> It's obvious there's a serious problem with a basic implementation of
events
> in remoting, the Server pauses while each Client processes the event. I've
> been through the basic Chat samples online, and if you purposefully hang
one
> client, none of the other clients proceeding get the event.
>
> What's the solution? I've found several areas on the web that talk about
> this but each example is overly complicated or incomplete.
>
> Is there a way to have the Server fire off an event that will not be
> dependent on the Client responding appropriately?
4 Answers

Seebs

10/22/2009 1:49:00 PM

0

On 2009-10-22, Dik T. Winter <Dik.Winter@cwi.nl> wrote:
> In article <b4c75ead-4e8e-4c16-b167-b41550a1ea18@e4g2000prn.googlegroups.com> spinoza1111 <spinoza1111@yahoo.com> writes:
> ...
> > There is no evidence in Schildt that he recommends using
> > incrementation to invalidly explore a stack, and there is evidence in
> > what you post that you are willing to recommend doing things like this
> > as when you recommended longjmp without mentioning that it is legacy.

> You are lying.

Objection! Assumes facts not in evidence. An allegation of lying refers
to the writer's internal awareness.

We do not have evidence showing that spinoza1111 can comprehend simple
sentences reliably, therefore, it is not justified to accuse him of lying
when he reports things contrary to what other readers thought a sentence
meant.

> Peter recommended *looking* at setjmp/longjmp as a routine
> where the logical order of call unwinding was not performed (which he
> understood was the original question).

Yes.

That said, I don't think the word "legacy" changes anything; I'm not aware
of any plans to discontinue those functions, and if you know what they are
for and how to use them, they may be reasonable choices. (It's worth noting
though that, in all the time I've been writing C, I don't think I've EVER
used them.)

-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seeb... <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/...(Scientology) <-- get educated!

Clot Hears

10/22/2009 2:43:00 PM

0

In article <slrnhe0ovs.np2.usenet-nospam@guild.seebs.net>,
Seebs <usenet-nospam@seebs.net> wrote:

> On 2009-10-22, Dik T. Winter <Dik.Winter@cwi.nl> wrote:
> > In article
> > <b4c75ead-4e8e-4c16-b167-b41550a1ea18@e4g2000prn.googlegroups.com>
> > spinoza1111 <spinoza1111@yahoo.com> writes:
> > ...
> > > There is no evidence in Schildt that he recommends using
> > > incrementation to invalidly explore a stack, and there is evidence in
> > > what you post that you are willing to recommend doing things like this
> > > as when you recommended longjmp without mentioning that it is legacy.
>
> > You are lying.
>
> Objection! Assumes facts not in evidence. An allegation of lying refers
> to the writer's internal awareness.
>
> We do not have evidence showing that spinoza1111 can comprehend simple
> sentences reliably, therefore, it is not justified to accuse him of lying
> when he reports things contrary to what other readers thought a sentence
> meant.

He certainly can't produce them, that's for damn sure.
--
Clothears

(Edward G. Nilges)

10/22/2009 3:46:00 PM

0

On Oct 22, 9:49 pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2009-10-22, Dik T. Winter <Dik.Win...@cwi.nl> wrote:
>
> > In article <b4c75ead-4e8e-4c16-b167-b41550a1e...@e4g2000prn.googlegroups.com>spinoza1111<spinoza1...@yahoo.com> writes:
> > ...
> > > There is no evidence in Schildt that he recommends using
> > > incrementation to invalidly explore a stack, and there is evidence in
> > > what you post that you are willing to recommend doing things like this
> > > as when you recommended longjmp without mentioning that it is legacy.
> > You are lying.
>
> Objection!  Assumes facts not in evidence.  An allegation of lying refers
> to the writer's internal awareness.
>
> We do not have evidence showing thatspinoza1111can comprehend simple
> sentences reliably, therefore, it is not justified to accuse him of lying
> when he reports things contrary to what other readers thought a sentence
> meant.
>
> > Peter recommended *looking* at setjmp/longjmp as a routine
> > where the logical order of call unwinding was not performed (which he
> > understood was the original question).
>
> Yes.
>
> That said, I don't think the word "legacy" changes anything; I'm not aware
> of any plans to discontinue those functions, and if you know what they are
> for and how to use them, they may be reasonable choices.  (It's worth noting
> though that, in all the time I've been writing C, I don't think I've EVER
> used them.)

You would have been on Herb like a fly on shit had he so much as
mentioned these statements beyond merely mentioning their existence
for the same reason you deliberately and maliciously interpreted his
use of a concrete implementation of a stack as the belief that the
stack *must* have that layout. You consistently and wrongly assume
that people know computer science iff they use fashionable (non-
Microsoft) platforms and what this establishes is that you can't think
in difficult environments that don't pander to your prejudices.

Shibboleths replace listening. And when you are treated as you have
maligned Schildt you whine like a baby.

Navia was able to clarify the semantics in the best way to clarify
semantics, which is to present a concrete, mathematically
intuitionist, construction with clearly essential features (the LIFO
property) of a stack alongside accidents (its order and the
implementation of push and pop, which changes depending on the stack
layout).

You prefer to sound sage without informing or mentoring by saying what
is not the case, condemning your auditors to an ignorance which you
intend.

You need to remove your attack on Schildt and apologize to him.
>
> -s
> --
> Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/... lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/...(Scientology) <-- get educated!

Flash Gordon

10/22/2009 7:06:00 PM

0

Dik T. Winter wrote:
> In article <slrnhdvilt.s2q.usenet-nospam@guild.seebs.net> Seebs <usenet-nospam@seebs.net> writes:
> ...
> > The objection is not to the term itself, but to a particular interpretation
> > of it. Basically, if someone refers to the call frames, etc., as "the
> > stack", the chances are about 9:1 that they think it's a single contiguous
> > region of memory with monotonically decreasing addresses, and this is not
> > a particularly good way to conceptualize it;
>
> Strange enough, the first machines I did program had a stack with *increasing*
> addresses, it was ony when I encountered the PDP that I saw a machine where
> it was commonly done differently.

One of the processors I used to program (the first I programmed in C, in
fact), had a hardware stack in a very pure form. A call pushed the
return address on to the stack and a return popped it off. The only
other instuctions that allowed you to access it were the push
instruction (pushing a value on) and pop instuction (popping it off).
You literally could *not* read any item on the stack except by popping
items until you reached the one you wanted. This is very different from
hardware stacks on other processors, and is of no use for a lot of the
implementation of "call frames", i.e. you could not use it for local
variables.

It also had a number of index registers any of which *could* be used to
increment a contiguous stack, and there was nothing in the processor
that made it prefer growing in any particular direction.
--
Flash Gordon