В Пт, 17/06/2022 в 21:15 +, adr пишет:
> On Fri, 17 Jun 2022, andrey100100...@gmail.com wrote:
> > Seems like noted() call not needed in user code.
>
> noted() is only needed when using the syscall notify, when using
> atnotify() (or threadnotify) you don't need it, as it is said in
> notify(2
On Fri, 17 Jun 2022, andrey100100...@gmail.com wrote:
Seems like noted() call not needed in user code.
noted() is only needed when using the syscall notify, when using
atnotify() (or threadnotify) you don't need it, as it is said in
notify(2) and you did correctly in your first example. threadn
On 6/17/22 12:48, andrey100100...@gmail.com wrote:
> В Пт, 17/06/2022 в 10:11 -0600, Jacob Moody пишет:
>> On 6/17/22 09:06, andrey100100...@gmail.com wrote:
>>> В Пт, 17/06/2022 в 08:11 -0600, Jacob Moody пишет:
On 6/17/22 07:46, Thaddeus Woskowiak wrote:
> I believe threadnotify() should
В Пт, 17/06/2022 в 10:11 -0600, Jacob Moody пишет:
> On 6/17/22 09:06, andrey100100...@gmail.com wrote:
> > В Пт, 17/06/2022 в 08:11 -0600, Jacob Moody пишет:
> > > On 6/17/22 07:46, Thaddeus Woskowiak wrote:
> > > > I believe threadnotify() should be called from threadmain() to
> > > > properly re
On Fri, 17 Jun 2022, Skip Tavakkolian wrote:
Thanks to Douglas Adams, I think '42' might be a more obvious magic
number for a clue:
% 8c udpflood.c && 8l -o udpflood udpflood.8 && ./udpflood | grep end | wc -l
42
% grep 42 /sys/src/libthread/note.c
#define NFN 42
I don't understand, why do
Thanks to Douglas Adams, I think '42' might be a more obvious magic
number for a clue:
% 8c udpflood.c && 8l -o udpflood udpflood.8 && ./udpflood | grep end | wc -l
42
% grep 42 /sys/src/libthread/note.c
#define NFN 42
On Fri, Jun 17, 2022 at 9:11 AM Skip Tavakkolian
wrote:
>
> it's worth g
On 6/17/22 09:06, andrey100100...@gmail.com wrote:
> В Пт, 17/06/2022 в 08:11 -0600, Jacob Moody пишет:
>> On 6/17/22 07:46, Thaddeus Woskowiak wrote:
>>> I believe threadnotify() should be called from threadmain() to
>>> properly register the handler in the rendez group
>>
>> This is incorrect, ac
it's worth grepping for persistent magic constants:
% grep 33 /sys/src/libthread/*.[ch]
/sys/src/libthread/note.c:#define NFN 33
On Fri, Jun 17, 2022 at 9:08 AM Skip Tavakkolian
wrote:
>
> interesting catch. it seems to be a tunable limit.
>
> % grep NFN /sys/src/libthread/note.c
> #define NFN 3
interesting catch. it seems to be a tunable limit.
% grep NFN /sys/src/libthread/note.c
#define NFN 33
static int (*onnote[NFN])(void*, char*);
static int onnotepid[NFN];
for(i=0; i wrote:
>
> В Пт, 17/06/2022 в 08:11 -0600, Jacob Moody пишет:
> > On 6/17/22 07:46, Thaddeus Woskowiak wrote:
> > >
В Пт, 17/06/2022 в 08:11 -0600, Jacob Moody пишет:
> On 6/17/22 07:46, Thaddeus Woskowiak wrote:
> > I believe threadnotify() should be called from threadmain() to
> > properly register the handler in the rendez group
>
> This is incorrect, according to thread(2):
>
> "The thread library depends
On Fri, Jun 17, 2022 at 10:13 AM Jacob Moody wrote:
>
> On 6/17/22 07:46, Thaddeus Woskowiak wrote:
> > I believe threadnotify() should be called from threadmain() to
> > properly register the handler in the rendez group
>
> This is incorrect, according to thread(2):
>
> "The thread library depend
On 6/17/22 07:46, Thaddeus Woskowiak wrote:
> I believe threadnotify() should be called from threadmain() to
> properly register the handler in the rendez group
This is incorrect, according to thread(2):
"The thread library depends on all procs
being in the same rendezvous group"
The issue here
I believe threadnotify() should be called from threadmain() to
properly register the handler in the rendez group.
On Fri, Jun 17, 2022 at 5:39 AM wrote:
>
> Hi all!
>
> Strange behavior of syscall 'read' with signal 'alarm' in followed
> simple program (ip/port - not matter):
>
> -
Hi all!
Strange behavior of syscall 'read' with signal 'alarm' in followed
simple program (ip/port - not matter):
---
#include
#include
#include
static int
handler_alarm(void *, char *msg)
{
if(strstr(msg, "alarm"))
14 matches
Mail list logo
