config/parisc/common.h

[Godmar Back]

> 
> Don't run Kaffe from Midnight Commander with subshell support, otherwise
> you would get
> 
> FIOSSAIOSTAT: Invalid argument
> ./systems/unix-jthreads/internal.c:114: failed assertion `mainthread'
> ABORT instruction (core dumped)

Pavel,

if that FIOSSAIOSTAT thing (whatever it's for) fails in certain situations,
we either have to know what errno we're seeing and take it into account,
or we'll just ignore the failure.  There's no reason kaffe shouldn't be
able to run from the midnight commander.

Basically, if we can't get an fd in async mode what will happen is that
we have to poll, we which do 5 times a second: so fds that do not support
async io might see slower I/O in cases where the first read or write
attempt fails with EWOULDBLOCK.  I'm hoping that this will only
concern things such as flow-controlled output queues on virtual terminals
where this rarely happens and rarely matters.

On an unrelated note, in common.h, you write:

  /* FIXME: we must make sure that stack has sufficient size */         \
  /* for all arguments!!! Maybe __builtin_alloca ? */                   \

Kaffe currently does not check for stack overflow; checking in
sysdepCallMethod only would not help that because the stack can overflow
in a native method as well.  We are also unable to automatically expand
a thread's stack (except for the main thread's stack, where the OS does
that.)  If anybody knows a reasonably clean and portable way of 
implementing expansible thread stacks in user-mode, I'd like to hear it.
Maybe it could be based on a scheme that handles segviolations on an
alternate stack and that uses mmap to manage virtual memory, but that
seems like a long shot and very OS dependent at that.  Alloca doesn't do 
you any good because it only moves the stack pointer; it has no impact on 
the memory allocated and mapped for the stack.

	- Godmar