[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel-spec-edit] Issue 32 - threads
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]