OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel-spec-edit message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wsbpel-spec-edit] Issue 32 - threads

To be clear we don't actually allow multiple copies of onAlarm handlers
so we should take care to avoid creating the contrary impression (my
language below does not do an adequate job).


 -----Original Message-----
From: Satish Thatte 
Sent: Wednesday, November 05, 2003 6:13 PM
To: 'Sid Askary'; wsbpel-spec-edit@lists.oasis-open.org
Subject: RE: [wsbpel-spec-edit] Issue 32 - threads


I don't see any reason to talk about threads.  Everyone understands
concurrency (and if they don't they should :-)).  Threads, as you point
out, are a specific implementation and are actually different in the
different platforms.

In this case, the simple clarification needed is that each event
(message or alarm) creates an instance of the corresponding event
handler and every instance of an event handler is a separate environment
with its own copy of all things local to the handler.  This includes the
message (onEvent) variable used in the header of the handler as well as
the links internal to the handler.  Given that links cannot cross event
handler boundaries the separate environment clarification should clear
any doubts.



-----Original Message-----
From: Sid Askary [mailto:saskary@nuperus.com] 
Sent: Wednesday, November 05, 2003 2:17 PM
To: wsbpel-spec-edit@lists.oasis-open.org
Subject: [wsbpel-spec-edit] Issue 32 - threads

The resolution for issue 32 was a one-sentence response.  Looking at the

notes, I see that I asked that we clarify and expand on the wording.
Now I 
remember why.  The entire spec does not mention the word "thread"- this 
despite a section on concurrency.  I know that we are trying to be
neutral and assume a lot of implementation specific criteria, but we
talk about threads without taking about a lot of other things.

For example:
Thread synchronization within BPEL
Thread safety (locks on resources, etc) within "programming language
Thread model (Monitor, semaphore, etc) between/within "run-time
Kinds of threads (POSIX, win32, etc.) between /within OS
Categories of threads (Kernel, User, etc.) within OS.
CPU (Von Neuman architecture, MP, etc).

I know that the above list may be going a bit too far, but not all code
written in languages and run-time environments that make that thread
transparent not are they run on OSs that are implementing threads -
are all assumptions that need to be clarified.

So, starting at the top, I would like to have an understanding on the
thread model (assumed or otherwise).

What do you think?

-- Sid.

To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]