They have been mentioned a few times, so I decided to take a look.

And I am puzzled.

Normally (pthreads, Win32, Boost/C++11, Java, .NET etc.) threads are
about starting a bunch of independent threads that does some work
in parallel.

But when I look at EXE$KP_START, EXE$KP_STALL_GENERAL, EXE$KP_RESTART
and EXE$KP_END then I do not see such capability.

Instead it is easy to see how to do coroutines with two streams
of execution but only one executing at a time transferring control
forth and back between the two streams (pretty similar to Modula-2
ISO COROUTINES TRANSFER).

What am I missing?

Arne

On Thursday, December 23, 2021 at 10:26:00 AM UTC-5, Arne Vajhøj wrote:
> Normally (pthreads, Win32, Boost/C++11, Java, .NET etc.) threads are
> about starting a bunch of independent threads that does some work
> in parallel.
>
> But when I look at EXE$KP_START, EXE$KP_STALL_GENERAL, EXE$KP_RESTART
> and EXE$KP_END then I do not see such capability.
>
> Instead it is easy to see how to do coroutines with two streams
> of execution but only one executing at a time transferring control
> forth and back between the two streams (pretty similar to Modula-2
> ISO COROUTINES TRANSFER).
>

Kernel processes are system context threads provided to give device drivers
that need them a private stack. That they look like coroutines fits in with the
rest of I/O request processing.

On Thursday, December 23, 2021 at 3:14:42 PM UTC-5, John Dallman wrote:
> I agree. The KP_ routines seem, looking at the explanation in Appendix C
> of "Porting Applications from Alpha to IA64," to have been created to let
> applications' internal coroutine systems work on IA-64. The hardware
> stack implementation on that architecture is a lot more complicated than
> VAX, or Alpha, or x86-64. It's fairly transparent if you use the stack
> simplistically, but it isn't really designed for DIY coroutines, or other
> clever trickery.
>

The origin of the Kernel Process Services goes back to 1990. That VEST-specific
areas are part of the parameter block leads me to think that was the original
motivation, plus the growing intricacies of things like the SCSI class driver.

On 2021-12-23 15:25:54 +0000, Arne Vajhj said:

> They have been mentioned a few times, so I decided to take a look.
>
> And I am puzzled.
>
> Normally (pthreads, Win32, Boost/C++11, Java, .NET etc.) threads are
> about starting a bunch of independent threads that does some work in
> parallel.

Since the canonical website for this material vaporized years ago,
here's a mirror containing a technical overview:

http://zx.net.nz/mirror/h71000.www7.hp.com/openvms/integrity/OpenVMS-KP-Services.pdf

--
Pure Personal Opinion | HoffmanLabs LLC

On 12/23/2021 3:59 PM, Stephen Hoffman wrote:
> On 2021-12-23 15:25:54 +0000, Arne Vajhj said:
>> They have been mentioned a few times, so I decided to take a look.
>>
>> And I am puzzled.
>>
>> Normally (pthreads, Win32, Boost/C++11, Java, .NET etc.) threads are
>> about starting a bunch of independent threads that does some work in
>> parallel.
>
> Since the canonical website for this material vaporized years ago,
> here's a mirror containing a technical overview:
>
> http://zx.net.nz/mirror/h71000.www7.hp.com/openvms/integrity/OpenVMS-KP-Services.pdf

That is pretty similar to what is in Appendix C.

Arne

On 12/23/2021 3:05 PM, David Jones wrote:
> On Thursday, December 23, 2021 at 10:26:00 AM UTC-5, Arne Vajhøj wrote:
>> Normally (pthreads, Win32, Boost/C++11, Java, .NET etc.) threads are
>> about starting a bunch of independent threads that does some work
>> in parallel.
>>
>> But when I look at EXE$KP_START, EXE$KP_STALL_GENERAL, EXE$KP_RESTART
>> and EXE$KP_END then I do not see such capability.
>>
>> Instead it is easy to see how to do coroutines with two streams
>> of execution but only one executing at a time transferring control
>> forth and back between the two streams (pretty similar to Modula-2
>> ISO COROUTINES TRANSFER).
>
> Kernel processes are system context threads provided to give device drivers
> that need them a private stack. That they look like coroutines fits in with the
> rest of I/O request processing.

I am sure they have their use.

But are you saying that the reason I can not see how I can use them
to start a bunch of threads utilizing all cores is that they can't
because they are not intended for that purpose?

Arne

On 12/23/2021 3:13 PM, John Dallman wrote:
> In article <61c49505$0$702$14726298@news.sunsite.dk>, arne@vajhoej.dk
> (Arne Vajhøj) wrote:
>> They have been mentioned a few times, so I decided to take a look.
>>
>> And I am puzzled.
>>
>> Normally (pthreads, Win32, Boost/C++11, Java, .NET etc.) threads are
>> about starting a bunch of independent threads that does some work
>> in parallel.
>
> It looks to me, from a bit of PDF-searching, as if the VMS idiom for that
> kind of threading is Kernel Threads, described in section 2.8 of VSI's
> Programming Concepts manual.

I have used pthreads before. Portable and standard paradigm. But I was
curious about what KP threads was all about.

>> But when I look at EXE$KP_START, EXE$KP_STALL_GENERAL,
>> EXE$KP_RESTART and EXE$KP_END then I do not see such capability.
>>
>> Instead it is easy to see how to do coroutines with two streams
>> of execution but only one executing at a time transferring control
>> forth and back between the two streams (pretty similar to Modula-2
>> ISO COROUTINES TRANSFER).
>
> I agree. The KP_ routines seem, looking at the explanation in Appendix C
> of "Porting Applications from Alpha to IA64," to have been created to let
> applications' internal coroutine systems work on IA-64. The hardware
> stack implementation on that architecture is a lot more complicated than
> VAX, or Alpha, or x86-64. It's fairly transparent if you use the stack
> simplistically, but it isn't really designed for DIY coroutines, or other
> clever trickery.

OK.

Arne