Resolved: (AXIS2-66) Binary Serialization support for SOAP Message

     [ 
https://issues.apache.org/jira/browse/AXIS2-66?page=com.atla
ssian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Davanum Srinivas resolved AXIS2-66.
-----------------------------------

    Resolution: Fixed

> Binary Serialization support for SOAP Message
> ---------------------------------------------
>
>                 Key: AXIS2-66
>                 URL: https:
//issues.apache.org/jira/browse/AXIS2-66
>             Project: Axis 2.0 (Axis2)
>          Issue Type: New Feature
>          Components: om
>            Reporter: Srinath Perera
>         Assigned To: Eran Chinthaka
>            Priority: Minor
>
> http://wiki.apache.org/ws/FrontPage/Axis2/Tas
ks/BinarySerialization

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue
online.


------------------------------------------------------------
---------
To unsubscribe, e-mail: axis-dev-unsubscribews.apache.org
For additional commands, e-mail: axis-dev-helpws.apache.org

On Thu, Apr 05, 2007 at 03:36:54PM +0200, Stéphane Letz
wrote:
> 
> Le 5 avr. 07 à 15:08, Fons Adriaensen a écrit :
> 
> > On Thu, Apr 05, 2007 at 02:12:48PM +0200, Stéphane
Letz wrote:
> >
> >> The final solution seems quite elegant now,
and I have implemented
> >> and tested it, but I don't see the point of
keeping the "status"
> >> parameter in jack_thread_wait anymore.
> >> What would be the meaning of
"status" now?
> >
> > Whatever is the meaning of the process_callback()
return code.
> > It has exactly the same role: it indicates the
'status' of the
> > user code whenever control passes from user code
to library.
> >
> > Using the 'waiting' interface means that the
calling direction is
> > reversed. Compare these:
> >
> > Pure callback mode:
> >
> >    - process_callback() always returns without
calling  
> > jack_thread_wait().
> >    -> the library is calling the user code.
> >
> > Pure waiting mode:
> >
> >    - process_callback() never returns but always
calls  
> > jack_thread_wait().	
> >    -> the user code is calling the library.
> >
> > The conclusion of the previous 'thinking steps' is
that the two
> > can be seamlessly merged: a client could even mix
both modes
> > depending on the circumstances, and jack wouldn't
feel any
> > difference.
> >
> > Reversing the calling direction means:
> >
> >   function argument becomes return code
> >   return code becomes function argument
> >
> > Hence the return code of the callback must be the
argument of
> > jack_thread_wait, and vice versa.
> 

> But the callback return code is also used as a way to
"stop" processing.
> So what would be the behaviour of:
> 
> int process(jack_nframes_t nframes, void *arg)
> {
> 	while (1) {
> 		SomeProcess1();
> 		nframes  = jack_thread_wait(client, 0);   	<==
should mean process  
> continue??
> 		SomeProcess2();
> 		nframes  = jack_thread_wait(client, -1); 	<==
should mean process  
> stops??
> 	}
> 
> 	return 0;
> }

Yes and yes.

And if you implement things as suggested in my previous
posts this
will automagically happen.

Think about this:

  The library code shouldn't know the difference between
process()
  returning, or calling jack_thread_wait(). Whatever action
it takes
  should not depend on which of the two happens. If
process() returns,
  the code in the while(1) loop in the library will call
jack_thread_wait().
  From that point on, you don't know how you got there, by a
return or
  by a call.

> The problem I see is how the user-code (process) is
going to stop  
> processing... if it is not using the "status"
parameter of   
> jack_thread_wait, then why keeping it?

It _does_ use the status parameter, with exactly the same
value as it
would return if it was using the pure callback model. If
non-zero,
then jack_thread_wait() will never return.

 
> Should we have something like:
> 
> int process(jack_nframes_t nframes, void *arg)
> {
> 	while (1) {
> 		SomeProcess1();
> 		nframes  = jack_thread_wait(client);
> 		if (nframes == 0)    <=== would mean : library
code detected an  
> error condition (like server has quitted...)
> 			return -1;
> 		SomeProcess2();
> 		nframes  = jack_thread_wait(client); 	
> 		if (nframes == 0)    <=== would mean : library
code detected an  
> error condition (like server has quitted...)
> 			return -1;
> 		......
> 	}
> 
> 	return 0;
> }

No, you are again introducing an assymetry. The nframes
parameter is
not used in this way as an argument for process(), hence it
should not
be used in this way as the return value of
jack_thread_wait(). Nor is 
here any need to do so.

The point to see here is that from the library's PoV _there
are not
two different modes_  It's always the same thing - see the
code below.

> I like symmetry also but I'm not sure it can completely
be done.

I'd be much surprised if it would turn out that it can't.
(mathematical intuition 

The difficulty which I think you are facing is this:

In the existing model and code, when process() returns you
are in
the same thread and the same scope that called it - it was
just a
function call. This means you will still have a valid
client*
somewhere in a local variable. 

In the new model, when jack_thread_wait is called, it also
executes
in the same thread that called process(), but you have a new
function
scope - there are now two unterminated function calls on the
stack.
If jack_thread_wait() returns (normal case) this doesn't
matter, as
you then have the same situation as after the call to
process().
If jack_thread_wait() decides not to return, then this
thread should
be terminated anyway, so again there should be no problem
with still
having two calls on the stack - you can terminate a thread
from
within any number of nested functions.

Since in jack_thread_wait() you are in a different function
scope
compared to where process() was called, you need the client*
argument.
But in theory you could also find the client* from the
thread_id.
If you find an efficient means to do this then that would be
the
most elegant way, but it's not essential.


The audio thread code I have in mind is like this (reduced
to the
essential):


void thread_main (jack_client_t *C)
{
   INITIALISE_CLIENT()

   while (true)
   {
       C->nframes = jack_thread_wait (C, C->process
(C->nframes));	
   } 
}


jack_nframes_t jack_thread_wait (jack_client_t *C, int
status)
{
   if (status)
   {
        CLEANUP_CLIENT() 	
        TERMINATE_THREAD() // does not return
   }
   WAIT_UNTIL_READY_TO_RUN_PROCESS_AGAIN()

   return C->nframes;		
}

This will handle both 'modes' transparently.


It is just a re-arrangement of what you have now:


void thread_main (jack_client_t *C)
{
   INITIALISE_CLIENT()

   while (true) 
   {
        status = C->process (C->nframes);	
	if (status)
        {
            CLEANUP_CLIENT() 	
	    TERMINATE_THREAD() // does not return
        }
        WAIT_UNTIL_READY_TO_RUN_PROCESS_AGAIN()
    }
}


-- 
FA

Follie! Follie! Delirio vano è questo !



------------------------------------------------------------
-------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the
chance to share your
opinions on IT & business topics through brief
surveys-and earn cash
http://www.techsay.com/default.
php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el

Le 5 avr. 07 à 17:33, Fons Adriaensen a écrit :

> On Thu, Apr 05, 2007 at 03:36:54PM +0200, Stéphane Letz
wrote:
>>
>> Le 5 avr. 07 à 15:08, Fons Adriaensen a écrit :
>>
>>> On Thu, Apr 05, 2007 at 02:12:48PM +0200,
Stéphane Letz wrote:
>>>
>>>> The final solution seems quite elegant now,
and I have implemented
>>>> and tested it, but I don't see the point of
keeping the "status"
>>>> parameter in jack_thread_wait anymore.
>>>> What would be the meaning of
"status" now?
>>>
>>> Whatever is the meaning of the
process_callback() return code.
>>> It has exactly the same role: it indicates the
'status' of the
>>> user code whenever control passes from user
code to library.
>>>
>>> Using the 'waiting' interface means that the
calling direction is
>>> reversed. Compare these:
>>>
>>> Pure callback mode:
>>>
>>>    - process_callback() always returns without
calling
>>> jack_thread_wait().
>>>    -> the library is calling the user code.
>>>
>>> Pure waiting mode:
>>>
>>>    - process_callback() never returns but
always calls
>>> jack_thread_wait().	
>>>    -> the user code is calling the library.
>>>
>>> The conclusion of the previous 'thinking steps'
is that the two
>>> can be seamlessly merged: a client could even
mix both modes
>>> depending on the circumstances, and jack
wouldn't feel any
>>> difference.
>>>
>>> Reversing the calling direction means:
>>>
>>>   function argument becomes return code
>>>   return code becomes function argument
>>>
>>> Hence the return code of the callback must be
the argument of
>>> jack_thread_wait, and vice versa.
>>
>
>> But the callback return code is also used as a way
to "stop"  
>> processing.
>> So what would be the behaviour of:
>>
>> int process(jack_nframes_t nframes, void *arg)
>> {
>> 	while (1) {
>> 		SomeProcess1();
>> 		nframes  = jack_thread_wait(client, 0);   	<==
should mean process
>> continue??
>> 		SomeProcess2();
>> 		nframes  = jack_thread_wait(client, -1); 	<==
should mean process
>> stops??
>> 	}
>>
>> 	return 0;
>> }
>
> Yes and yes.
>
> And if you implement things as suggested in my previous
posts this
> will automagically happen.
>
> Think about this:
>
>   The library code shouldn't know the difference
between process()
>   returning, or calling jack_thread_wait(). Whatever
action it takes
>   should not depend on which of the two happens. If
process() returns,
>   the code in the while(1) loop in the library will
call  
> jack_thread_wait().
>   From that point on, you don't know how you got there,
by a return or
>   by a call.
>
>> The problem I see is how the user-code (process) is
going to stop
>> processing... if it is not using the
"status" parameter of
>> jack_thread_wait, then why keeping it?
>
> It _does_ use the status parameter, with exactly the
same value as it
> would return if it was using the pure callback model.
If non-zero,
> then jack_thread_wait() will never return.
>
>
>> Should we have something like:
>>
>> int process(jack_nframes_t nframes, void *arg)
>> {
>> 	while (1) {
>> 		SomeProcess1();
>> 		nframes  = jack_thread_wait(client);
>> 		if (nframes == 0)    <=== would mean : library
code detected an
>> error condition (like server has quitted...)
>> 			return -1;
>> 		SomeProcess2();
>> 		nframes  = jack_thread_wait(client); 	
>> 		if (nframes == 0)    <=== would mean : library
code detected an
>> error condition (like server has quitted...)
>> 			return -1;
>> 		......
>> 	}
>>
>> 	return 0;
>> }
>
> No, you are again introducing an assymetry. The nframes
parameter is
> not used in this way as an argument for process(),
hence it should not
> be used in this way as the return value of
jack_thread_wait(). Nor is
> here any need to do so.
>
> The point to see here is that from the library's PoV
_there are not
> two different modes_  It's always the same thing - see
the code below.
>
>> I like symmetry also but I'm not sure it can
completely be done.
>
> I'd be much surprised if it would turn out that it
can't.
> (mathematical intuition 
>
> The difficulty which I think you are facing is this:
>
> In the existing model and code, when process() returns
you are in
> the same thread and the same scope that called it - it
was just a
> function call. This means you will still have a valid
client*
> somewhere in a local variable.
>
> In the new model, when jack_thread_wait is called, it
also executes
> in the same thread that called process(), but you have
a new function
> scope - there are now two unterminated function calls
on the stack.
> If jack_thread_wait() returns (normal case) this
doesn't matter, as
> you then have the same situation as after the call to
process().
> If jack_thread_wait() decides not to return, then this
thread should
> be terminated anyway, so again there should be no
problem with still
> having two calls on the stack - you can terminate a
thread from
> within any number of nested functions.
>
> Since in jack_thread_wait() you are in a different
function scope
> compared to where process() was called, you need the
client* argument.
> But in theory you could also find the client* from the
thread_id.
> If you find an efficient means to do this then that
would be the
> most elegant way, but it's not essential.
>
>
> The audio thread code I have in mind is like this
(reduced to the
> essential):
>
>
> void thread_main (jack_client_t *C)
> {
>    INITIALISE_CLIENT()
>
>    while (true)
>    {
>        C->nframes = jack_thread_wait (C,
C->process (C->nframes));	
>    }
> }
>
>
> jack_nframes_t jack_thread_wait (jack_client_t *C, int
status)
> {
>    if (status)
>    {
>         CLEANUP_CLIENT() 	
>         TERMINATE_THREAD() // does not return
>    }
>    WAIT_UNTIL_READY_TO_RUN_PROCESS_AGAIN()
>
>    return C->nframes;		
> }
>
> This will handle both 'modes' transparently.
>
>
> It is just a re-arrangement of what you have now:
>
>
> void thread_main (jack_client_t *C)
> {
>    INITIALISE_CLIENT()
>
>    while (true)
>    {
>         status = C->process (C->nframes);	
> 	if (status)
>         {
>             CLEANUP_CLIENT() 	
> 	    TERMINATE_THREAD() // does not return
>         }
>         WAIT_UNTIL_READY_TO_RUN_PROCESS_AGAIN()
>     }
> }
>
>


Ok, it's implemented in jackdmp exp branch.

svn co h
ttp://subversion.jackaudio.org/jackmp/branches/exp

Testing and comments appreciated!

Stephane
------------------------------------------------------------
-------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the
chance to share your
opinions on IT & business topics through brief
surveys-and earn cash
http://www.techsay.com/default.
php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el