[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel-spec-edit] Issue 32 - threads
Paco, I'll post it out mid-day tomorrow. Is that okay with you? Sid. At 01:42 PM 11/7/2003, Francisco Curbera wrote: >Sid, > >I am not sure what is the current status; I assume you are editing right >now and will let me know when I can take the pen. > >Thanks, > >Paco > > > > "Satish Thatte" > <satisht@microsof To: "Sid Askary" <saskary@nuperus.com>, <wsbpel-spec-edit@lists.oasis-open.org> > t.com> cc: > Subject: RE: [wsbpel-spec-edit] Issue 32 - threads > 11/05/2003 09:15 > PM > > > > > >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). > >Satish > > -----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 > >Sid, > >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. > >Satish > > > >-----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 > >All, >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 >platform >neutral and assume a lot of implementation specific criteria, but we >cannot >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 >code" >Thread model (Monitor, semaphore, etc) between/within "run-time >environment" >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 >is >written in languages and run-time environments that make that thread >usage >transparent not are they run on OSs that are implementing threads - >these >are all assumptions that need to be clarified. > >So, starting at the top, I would like to have an understanding on the >BPEL >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 >http://www.oasis-open.org/apps/org/workgroup/wsbpel-spec-edit/members/le >ave_workgroup.php. > > > > >To unsubscribe from this mailing list (and be removed from the roster of >the OASIS TC), go to >http://www.oasis-open.org/apps/org/workgroup/wsbpel-spec-edit/members/leave_workgroup.php >.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]