public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [RFD] new syscalls: suspend_other/resume_other?
@ 2007-09-02 15:04 Ingo Oeser
  2007-09-02 15:36 ` Alan Cox
  2007-09-07 11:53 ` Pavel Machek
  0 siblings, 2 replies; 3+ messages in thread
From: Ingo Oeser @ 2007-09-02 15:04 UTC (permalink / raw)
  To: linux-kernel

Hi there,

at the moment implementing a mark and sweep garbage collection 
subsystem is quite a hack, because you always have to use up
some signals for suspend/resume all threads to implement this.

For runtime environments (like D system libraries or JVMs) this is 
a hack, since you take away flexibility from the application.

A possible solution would be a syscall or a PTRACE extension
to realize the suspend/resume. I best describe the possible
syscall manpages here, so you get an idea.

NAME 
	suspend_other - suspends execution of all but the calling thread

SYNOPSIS
	long suspend_other(void);

RETURN VALUE
	Positive count suspended threads on success. 
        If 0, then suspend_other was a no-op and there is nothing to resume, but the
	call should still considered successful.
	If the number is -1, the errno has to be checked for possible error values.

ERRORS
	EDEADLK We run already a suspend_other() and the calling thread 
		has just been resumed.

	EPERM The calling thread is not allowed to do this. 
		(optional case due to security)
	
DESCRIPTION
	After sucessful return of this call, the affected process 
	is single threaded and only the calling thread runs 
	in this process (==MM struct).

	The thread, which calls this is responsible for resuming 
	all the suspended threads. One can iterate through 
	"/proc/self/task/", to verify for sure that one knows all threads,
	if the returned count doesn't match the expected value.

	Any per thread queued signals are deferred until resume_other()
	or process destruction.

NOTES
	This call might be restricted to the main thread.

------------

NAME 
	resume_other - resume execution of foreign thread in this process

SYNOPSIS
	long resume_other(pid_t tid)

RETURN VALUE
	Returns 0, if successful.
	Otherwise -1 is returned, the errno has to be checked for 
	possible error values and the call has no effect at all.

	Any non-blocked signals of that thread which happend during 
	suspend/resume are deliverd now.

ERRORS
	EINVAL The thread is running already. 
		(this is a severe caller BUG).
	ESRCH The thread with tid does not exist.
		(or doesn't belong to this process).
	EPERM The calling thread is not allowed to do this. 
		(optional case due to security)
	
DESCRIPTION
	After sucessful return of this call, the affected thread 
	is the the state it was before it was suspended 
	by calling suspend_other().

NOTES
	The value -1 for tid is reserved for future extension 
	(e.g. meaning ALL other threads).

	This call might be restricted to the main thread.

---------

Any opinions?


Best Regards

Ingo Oeser

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [RFD] new syscalls: suspend_other/resume_other?
  2007-09-02 15:04 [RFD] new syscalls: suspend_other/resume_other? Ingo Oeser
@ 2007-09-02 15:36 ` Alan Cox
  2007-09-07 11:53 ` Pavel Machek
  1 sibling, 0 replies; 3+ messages in thread
From: Alan Cox @ 2007-09-02 15:36 UTC (permalink / raw)
  To: Ingo Oeser; +Cc: linux-kernel

> 	After sucessful return of this call, the affected process 
> 	is single threaded and only the calling thread runs 
> 	in this process (==MM struct).

Not quite - vfork...

> 	This call might be restricted to the main thread.

What if differing threads have differing security credentials

And if you plan to suspend all the other threads wtf is wrong with
SIGSTOP ?

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [RFD] new syscalls: suspend_other/resume_other?
  2007-09-02 15:04 [RFD] new syscalls: suspend_other/resume_other? Ingo Oeser
  2007-09-02 15:36 ` Alan Cox
@ 2007-09-07 11:53 ` Pavel Machek
  1 sibling, 0 replies; 3+ messages in thread
From: Pavel Machek @ 2007-09-07 11:53 UTC (permalink / raw)
  To: Ingo Oeser; +Cc: linux-kernel

On Sun 2007-09-02 17:04:21, Ingo Oeser wrote:
> Hi there,
> 
> at the moment implementing a mark and sweep garbage collection 
> subsystem is quite a hack, because you always have to use up
> some signals for suspend/resume all threads to implement this.
> 
> For runtime environments (like D system libraries or JVMs) this is 
> a hack, since you take away flexibility from the application.
> 
> A possible solution would be a syscall or a PTRACE extension
> to realize the suspend/resume. I best describe the possible
> syscall manpages here, so you get an idea.
> 
> NAME 
> 	suspend_other - suspends execution of all but the calling thread

aha, this should really be named stop_other / cont_other, suspend is
already taken :-).
							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2007-09-07 11:53 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-09-02 15:04 [RFD] new syscalls: suspend_other/resume_other? Ingo Oeser
2007-09-02 15:36 ` Alan Cox
2007-09-07 11:53 ` Pavel Machek

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox