Re: Blocking syscalls in Tasks

[schwering <schwering@gmail.com>]

On 27 Sep., 20:40, "Peter C. Chapin" <pcc482...@gmail.com> wrote:
> schwer...@gmail.com wrote:
> > Are tasks commonly implemented using threads and does the language
> > specification request tasks to be in the user- or kernelspace? Or is
> > there a real difference between tasks and threads?
>
> My understanding is that this is left implementation defined. However,
> I'm sure those more expert than me will be able to give you a more
> definitive answer.
>
> Peter

My understanding is the same -- or at least I nowhere found something
else.
But I wonder about this, because in my opinion there is a great
difference between tasks = userspace threads and tasks = kernelspace
threads.

If I/O operations are be outsourced to a task for performance
considerations, but the syscalls for these I/O operations are blocking
the complete process (i.e. all running tasks), the outsourcing would
have no (positive) effect.
In this scenario, the I/O task could check whether the next I/O
syscall is blocking and perform it only if it is not. But this would
require an additional syscall (for this check) and would decrease the
performance again. Hence, I think there should at least be some way to
check whether in the given implementation of tasks blocking syscalls
block only the calling task or everything.

By the way, I just tested read()ing from stdin under OS X with GNAT.
This blocked only the read()ing task while other tasks. :-)

Greetings
Chris