> Thanks Bardwell.
> I'm getting to understand but have a few more questions.
>
> > The main problem is that the sub-applet is not able to finish starting
> > because the main applet hasn't gone into the event loop. If you
> > put the socket connecting code into an {after 5s do} instead of using
> > {sleep 5s} then it works.
>
> At first,let me make sure of a few things.
>
> Is it right that each applet have its own event loop?
Yes.
> If so, can I think {sleep} procedure makes other applets slept.
> I have thought the procedure has such effect on only its own thread and
> other applets' thread can run separately.
{sleep} does not make all of the applets sleep, but making an applet
{sleep} while a sub-applet is starting blocks the sub-applet from finishing
starting.
(I think that the problem is that the sub-applet needs to exchange some
messages with the parent applet during startup, but sleep is not the
event loop, so it isn't answering messages.)
> > However it might be easier (and more reliable, since it won't break >
> > due to the port already being in use) to just have the main applet
> > make the AcceptorTCPSocket without using an assigned local-port, do
> > {bind} and then create the sub-applet, passing it the local-port that
> > the AcceptorTCPSocket automatically allocated by putting the port
> > number in the query part of the Url. But that might not match how you
> > want your applets to be organized.
>
> this idea is good. I'll try this.
>
> >>{define-proc {accept-handler e:AcceptableSocketEvent}:void
> >> let sock:DataTCPSocket = {listener.accept}
> >
> > This could block, ideally you wrap the contents of the accept-handler
> > proc in {try catch e:WouldBlockSocketException do } and call the
> > accept with timeout = 0s.
>
>
> Let me make sure of the socket communication methods.
>
> when it's ok for applet to be blocked while communication process
> is running, I can write as bellow.
>
> let listener:AcceptorTCPSocket
> = {AcceptorTCPSocket
> local-port = 6001
> }
>
> {listener.bind}
>
> let b:bool = true
> {while b do
> let sock:DataTCPSocket = {listener.accept}
>
> || do something
> }
Yes, that is fine.
> And when it's needed to use asynchronous communication method
> I should write as bellow.
>
> let listener:AcceptorTCPSocket
> = {AcceptorTCPSocket
> local-port = 6001
> }
>
> {define-proc {accept-handler e:AcceptableSocketEvent}:void
> {try
>
> let sock:DataTCPSocket = {listener.accept timeout = 0s}
>
> catch e:WouldBlockSocketException do
> || there isn't connection which should always exists
> || when this event is invoked.
> }
> }
>
> Is these code written with right manner?
Yes, that is fine.
>
> >> {sender.shutdown DataSocketShutdownOption.input-output}
> >
> > I don't know what you are hoping to do with this, you really just need
> > to do {sender.close} and {output.close}.
>
> Honestly I don't understand enough about the usage of
> {DataTCPSocket.close} and {DataTCPSocket.shutdown}.
>
> Please tell me when each method should be used or shold not be used.
{close} should be used when the applet is done with the socket.
{shutdown} is used (with either input or output) when the protocol
requires it. Generally those are used in the following scenario:
program A sends a message that says that it is done, and it doesn't
want to send any more messages, but it wants to wait for the other
side to be done, or it wants to wait for more messages from the
other side, then program A will call
{shutdown DataSocketShutdownOption.output}, and then wait for a
messages or an EOF from the other side.
The key point of {shutdown DataSocketShutdownOption.output} is
that the other side of the socket can see the EOF from reading,
but can still write to the socket.
{shutdown DataSocketShutdownOption.input} is not used as much,
but a protocol could say that one side of a connection knows that
it doesn't want to receive more messages, but is still sending messages,
so it could call {shutdown DataSocketShutdownOption.input}, but I
am not sure that that call always does something.
{close} also calls {shutdown DataSocketShutdownOption.input-output}
for you. But you should always call {close} on both the DataTCPSocket
and the streams that you made from it when you are totally done
with the socket. (And you can close the DataTCPSocket without breaking
anything if you have streams that are still open, as long as you don't
need to do anymore DataTCPSocket method calls.)
William Bardwell
[EMAIL PROTECTED]
*******************************************
To unsubscribe from this list, send a mail to:
mailto:[EMAIL PROTECTED]
To contact a human list administrator, send a mail to:
mailto:[EMAIL PROTECTED]
To recieve a list of other options for this list, send a mail to:
mailto:[EMAIL PROTECTED]
