History log of /fuchsia/zircon/docs/syscalls/thread_create.md
Revision Date Author Comments
# 99387274 23-Jul-2018 George Kulakowski <kulakowski@google.com>

[docs][syscalls] Add TODOs about documenting system call rights

ZX-2399 #comment

Test: no functional change
Change-Id: I1f285c677e2444fcf1d720d7ecbd9f490c303962


# 013973ad 26-Jun-2018 Doug Evans <dje@google.com>

[docs][syscalls] Clarify ZX_ERR_NO_MEMORY as eventually going away

Not touched:
vmo_op_range.md
vmo_set_size.md
vmo_write.md
The current text is ok for these.

ZX-2303 #comment patch

Tested: Just doc changes, read before/after.

Change-Id: I2c6e1039e2b205e9cc377b9888755fa7ac676c78


# 9dd5b5f5 24-May-2018 Adam Barth <abarth@chromium.org>

[syscalls] Update parameter types and names

This CL updates the parameter types and names for a number of syscalls
to match the Zircon System API rubric. There's more work to do to make
all the syscalls conform to the rubric, but this change is a start.

Change-Id: I218ac5e7e0cbd80a8c69fef7891ad40b78b6b407


# fda5dc21 29-Nov-2017 Carlos Pizano <cpu@google.com>

[zircon][thread] Don't kill threads on handle close

This is a long awaited step on the lifetime
reformation referenced in ZX-820 and in ZX-1106

The basic concept, better stated in the bugs
is that threads running state is not modified
by the handle count, only by directly telling
the scheduler what to do with the thread
which naturally bottlenecks in either
thread_exit() or thread_kill()

-Update the tests that poked at this behavior.

-Update the documentation, which was already wrong,
even considering the code before the CL.

Change-Id: Ic86942e739991359a20201b996d81cafb75083f7


# f3e2126c 12-Sep-2017 Roland McGrath <mcgrathr@google.com>

[zx] Magenta -> Zircon

The Great Renaming is here!

Change-Id: I3229bdeb2a3d0e40fb4db6fec8ca7d971fbffb94


# 4e0f8792 09-Jun-2017 George Kulakowski <kulakowski@google.com>

[docs][errors] Rename all the errors in docs/ to MX_OK and MX_ERR_*

Change-Id: I62451456a83145760c6454a619d4c699ce8e9017


# dda8046e 17-May-2017 Carlos Pizano <cpu@google.com>

[magenta] cleanup deprected thread/process signal

MX_PROCESS_SIGNALED and MX_THREAD_SIGNALED have
been slated to be removed for a while now.

Can't remove them from the header because fuchsia
uses them. Only in like 4 places.

Change-Id: I068e1556d8bdc8cb5b57a6f9b011eb6e924a5836


# 7e86f15c 24-Feb-2017 George Kulakowski <kulakowski@google.com>

[syscalls] Uniformally use "options" rather than "flags" as a syscall parameter name

With the exception of the VMAR syscalls which really do want to talk
about map_flags.

Part of MG-559

Change-Id: I51673de824b4072990f01724a3bf522a9a84f4f4


# d4ba06df 23-Feb-2017 George Kulakowski <kulakowski@google.com>

[docs][syscalls] Fix all the manpages

Change-Id: Ie9ba25060f3331de8d9c178caf6332fb48fc80f5


# 9f287617 10-Feb-2017 Dave Bort <dbort@google.com>

[kernel][syscalls] Truncate long thread names

Make sys_thread_create and sys_process_create more similar.

Change-Id: If0b4cedf910e96515498435c306e587ba409b794


# 0c9d6f13 09-Feb-2017 Brian Swetland <swetland@google.com>

[syscalls] rename mx_handle_wait_*() to mx_object_wait_*()

These act on the object the handle refers to, not the handle itself.

Compatibility wrappers are provided to ensure existing code
continues to compile, link, and run. Later we will deprecate
the wrappers and eventually remove them.

Change-Id: Icf69e75f7e0c060ba6026343f9d26ff9da4317d9


# 1e2b3f9e 06-Jan-2017 George Kulakowski <kulakowski@google.com>

[docs] Update syscall docs to the new signal names

Change-Id: Ice62221ddd4493018c519052e17f3a49499f2695


# 9f25e9a0 15-Nov-2016 George Kulakowski <kulakowski@google.com>

[docs] Fix links to handle_wait_one.md

Change-Id: Ia8a3509759b264ecdce0cee910663999e8492df3


# ee4544ee 27-Oct-2016 Brian Swetland <swetland@google.com>

[syscalls] mx_thread_create() updated

Change-Id: I843d3a4a15f0f49bb91adc4ebd93ab8983916cb7


# 5d040605 04-Sep-2016 Brian Swetland <swetland@google.com>

[docs][syscalls] thread and process manpages

Change-Id: I539c21a5e6fbf56da1609d4daec00dc7e5d80c63